PEP 621 is not only for “Pure Python packaging” about scikit-hep.github.io HOT 9 CLOSED

Hello. Thank you for reporting. Feel encouraged to suggest a rephrasing with a MR - we appreciate contributions. Otherwise we will deal with this asap.

from scikit-hep.github.io.

I think it’s a bigger decision, since the page title is “Pure Python packaging”. I don’t know if the intention for that page is to showcase PEP 621 build backends or if you want to write a page about Pure Python packaging and the PEP 621 backends just happen to be the best option for that.

I think the only example for building native code with one of them so far is https://github.com/ofek/hatch-mypyc/, but I’m sure that’ll change: setuptools has a lot of cruft and is pretty slow, so some people will be happy to move on eventually.

from scikit-hep.github.io.

That's fair enough. OK, we will discuss.

from scikit-hep.github.io.

The problem is that there needs to be a clear "choose one", that is, why pick PEP 621 over classic config, or vice versa? Currently, while there are some limited examples of PEP 621 binary builders, there isn't a very good major one. Setuptools can do it, though you still need a setup.py too, there are a few examples of combing it with something like Hatch, and probably the best example is Maturin for Rust or masonpy (which wasn't cross-platform last I checked, and there's very little precedent for meson in HEP at least). I'm hoping to work on https://iscinumpy.dev/post/scikit-build-proposal/ which will provide a really good PEP 621 backend for binary projects, but that's not happening yet. That's one reason I was really interested in getting good PEP 621 docs up!

I think we can probably edit the language a little, but I don't think we can get away from the PEP 621 mostly for non-binary projects quite yet.

from scikit-hep.github.io.

(You'll notice the URL does not have "pure python" in it, that was intentional)

from scikit-hep.github.io.

I think we can probably edit the language a little

So something like the following, makes sense! “Fully specifying your package metadata in pyproject.toml (PEP 621) is the simplest way to package your project. At the time of writing, this option is only mature for pure Python projects without compiled extensions.”

from scikit-hep.github.io.

I think you've dealt with this by now, right @henryiii?

from scikit-hep.github.io.

I attempted to, yes. Thought I'd marked the PR to close this.

from scikit-hep.github.io.

You wrote

Partially addressing #200 as well.

I’m happy with the change though!

from scikit-hep.github.io.