Non-pre-release on PyPI, conda-forge? about jupyterlab-markup HOT 10 CLOSED

Well, I've been using it as a semi daily driver and it's not been problematic... I think we can drop the alpha label, perhaps see if we can find any bugs before hand!

A conda forge maintainer is very appreciated... Thanks a bunch!

from jupyterlab-markup.

1.0.0 has been released on PyPI. I'd be interested for you to take a look at new changes w.r.t CI/CD & general setup to see if you have any concerns - I did the upgrade to automated deployment and jupyter-packaging backend quite quickly 🚀

from jupyterlab-markup.

Started this, lemme know (on the ticket, for the record) if you want your name in there so you can push the button.

conda-forge/staged-recipes#14797

Will take a gander at CI-land...

from jupyterlab-markup.

• _version.py
  • the os.walk smells weird, your code should know where it's getting it's version
    • in this case, might recommend pkg = pathlib.Path(__file__).parent / "labextension/package.json
    • also ensure the encoding when reading, e.g. pkg.read_text(encoding="utf-8") before json.loads, as some widnows/weird locales are... weird
• __init.__py
  • this is also opening and looking for a package.json, would restrict this to __version__.py
    • i've been hoisting the whole parsed package.json data as __js__ or something like that
• setup.cfg
  • you have a trailing slash on the homepage, this will cause problems somemwhere
  • ideally source all of this available that exists from reading package.json, as that is where your runtime version-of-record comes from in setup.py
• i am not actually an enormous jupyter-packaging fan, mostly because of the jumping jacks required for downstreams (like conda-forge)
  • thank you for not making it a runtime dependency

from jupyterlab-markup.

• ci.yml looks like fine, though i recommend:
  • in pre-commit,
    • build the package, and use actions/upload to make it available
  • in test,
    • burning some more coal to make sure it works on at least windows (finds path gremlins)
    • use actions/download to grab the dist
    • use both the whl and sdist on different matrix dimensions to ensure that no important files are dropped
      • usually, it's enough to ensure labextension/package.json made it
    • at least verify the python package imports, and ideally check that version one last time, as read from the source of trust
• cd.yml
  • your call, if it helps you ship confidently:
    • i personally don't like putting creds into Other People's Computers, but that's just me.

from jupyterlab-markup.

@bollwyvl thanks for taking a look!

• _version.py

  • the os.walk smells weird, your code should know where it's getting it's version

    • in this case, might recommend pkg = pathlib.Path(__file__).parent / "labextension/package.json
    • also ensure the encoding when reading, e.g. pkg.read_text(encoding="utf-8") before json.loads, as some widnows/weird locales are... weird

I think this was originally from the conversion tool for JupyterLab 3.x. I'll make an issue to remove this and hard code the path. Thanks for the tip on locales. There are a few things like that (such as OS-specific file paths) that I don't always think about.

• __init.__py

  • this is also opening and looking for a package.json, would restrict this to __version__.py

    • i've been hoisting the whole parsed package.json data as __js__ or something like that

Wierd...

• setup.cfg

  • you have a trailing slash on the homepage, this will cause problems somemwhere
  • ideally source all of this available that exists from reading package.json, as that is where your runtime version-of-record comes from in setup.py

Yes, I would like to use something like setuptools_scm, I just haven't gotten around to that yet. Let me make another issue!

• i am not actually an enormous jupyter-packaging fan, mostly because of the jumping jacks required for downstreams (like conda-forge)

  • thank you for not making it a runtime dependency
    Yeah, I don't think it should ever be required at runtime for our purposes, just for building the wheel.

from jupyterlab-markup.

In the case of any jupyterlab stuff, i've just been using plain-old-setuptools, and eschewing build-system (and pyproject.toml, unless i need it for some linter) entirely. Some examples (pick the shortest!)

• https://github.com/deathbeds/ipydrawio/blob/master/py_packages/ipydrawio/setup.py
• https://github.com/jupyrdf/ipyelk/blob/master/setup.py

Some reasons:

• in CI:
  • being able to observe how jlpm and jupyter labextension build work is important to me, especially when they fail
    • if a failure occurs during a python build, it's way harder to debug
  • it's faster because
    • i'm not installing dependencies of a build chain
      • for its warts, setuptools doesn't really change its API much, and usually not without a reference PEP first
    • i'm not installing another environment, and jupyterlab is not exactly lightweight.
    • if I build a wheel and sdist, it runs the node junk twice without serious intervention
• locally:
  • i basically only develop on a conda env per project, using the binder/ci environment as the environment for the project
  • my wheel cache gets trashed all the time, because see above (different versions of pip, paths, etc)
  • if i'm building, i make sure my outer environment takes care of my build deps
    • but while i don't like "for real" continuous delivery, I do prefer to have my artifacts built and checksummed on CI... but sadly, until we have flit or something, it's non-trivial to get reproducible builds out of the whl, and folks keep dragging their feet on the reproducible sdist PR
  • I want one version, and it's gonna be checked into package.json anyway, so any fancy stuff is just a headache for when the poor sap (usually also me) wants to re-package it without a git checkout etc.

...and dear god, avoid versioneer.py like the plague.

from jupyterlab-markup.

• ci.yml looks like fine, though i recommend:

  • in pre-commit,

    • build the package, and use actions/upload to make it available

  • in test,

    • burning some more coal to make sure it works on at least windows (finds path gremlins)

    • use actions/download to grab the dist

    • use both the whl and sdist on different matrix dimensions to ensure that no important files are dropped

      • usually, it's enough to ensure labextension/package.json made it

    • at least verify the python package imports, and ideally check that version one last time, as read from the source of trust

• cd.yml

  • your call, if it helps you ship confidently:

    • i personally don't like putting creds into Other People's Computers, but that's just me.

The CI matrix rework is something I agree upon. I feel that it's unnecessary to build on multiple configurations when it a) shouldn't be built by end users and b) should not compile anything OS specific (though obviously the build steps might fail on some OS for .

I think I'll keep using pre-commit, because it's nice to be able to run the same tests + configurations during local dev, but I'll merge the lint + build steps into a single job.This way, I don't waste CPU + code doing everything "properly" in separate jobs.

For me, the benefit of having the deployment on GHA is just to automate the whole thing, so I can tie "release" with "push to PyPI". Hopefully having the secrets on GHA isn't going to bite me in the future 🤞

Thanks for the feedback, much appreciated.

from jupyterlab-markup.

Yeah, i avoid npm-related stuff whenever I can on windows, and am really sad when i have some feature that needs it... ipydrawio-export PDF is too good to turn down, but i'm still not happy with it.

pre-commit's fine, though again, it builds another environment. i have found on some projects that having linting be a separate step decreases anxiety for contributors... my ideal would some day be a friendly bot that suggests lint fixes so that folk just have to press the button, and only block merges to the main branch, but not show so much ✖️ .

yeah, it's great to have a tag be the real thing that drives everything, it makes me crazy when projects just push stuff, potentially from offline commits that never make it back up. really hard to track provenance. when i have been forced to move something to some other service, i had to set up a bot just for that, as my inner white hat screams at me... i trust encryption, but not when i don't know exactly where the ciphertext will be in RAM.

from jupyterlab-markup.

Ha, we did this 🎉

from jupyterlab-markup.