It’s saying that’s what it feels to me like others are saying.
As an individual, I feel like the consensus is moving towards something that doesn’t help any of the code that I write, so I’m indifferent to how things play out unless there’s a sudden pivot to support use cases like mine.
As PEP delegate, I’m trying to encourage people to find a clear statement of what they want the PEP to say, because it feels to me that the biggest problem here is lack of clarity, which means no-one can make a proper decision.
IMHO we can adopt the PEP as is, and not mandate backends to migrate (keep it an option instead). Give it a few years and they’ll gravitate towards that and in 5 years we end up where we want. My 2c.
I disagree on both points, if the PEP states that the fields under the [project] section must provide canonical information (like it currently does):
pip would certainly benefit from checking it first for dependencies information instead of invoking the whole PEP517 build isolation
as a distribution analyser, if you can directly access the desired information from a TOML file instead of relying on again invoking the PEP 517 mechanism or some clever heuristic statically analysing setup.py, I’d certainly go for it.
And as an user (if enough backends adopt it), it would mean less things to discover/learn when switching from one backend to an other.
I feel like it might be worth taking a quick poll on people’s views here, just to get a better sense of where we are. I don’t see this as a formal “vote” on whether the PEP should be accepted, more as “testing the water” to try to get a bit of clarity.
What is your view on PEP 621?
Accept it as it stands
Accept it without the extra “mandatory in sdists” requirements
Withdraw it
Turn it into an informational PEP defining the [project] table, but not mandating how tools use it
0voters
The second option is basically removing the “backends must update the file” requirement, but worded so we don’t accidentally say that backends can’t update pyproject.toml if they want to
I haven’t included “Other” as an option - if none of the choices appeal to you, just don’t vote and comment with your preferred approach
(Edit: I appear to have made the vote anonymous. I didn’t particularly mean to, but I won’t change it in case it discards votes that have already been cast. If anyone prefers it to be open, I’m OK to change it)
Just so people know, I am watching this poll closely in making my decision as to whether I want to stick with PEP 621, and if so what I will do with/to it. So if you do have any opinion, please vote.
Can we share wording from must to are encouraged to on the sdist topic? With this nudging in a few years, we’ll have it pretty much present everywhere IMHO.
Other fields which pertain to data surfaced on PyPI, and thus are not expected to be determined at wheel creation time, MUST NOT be listed as dynamic in a source distribution
and the corresponding “Source distributions: required” annotations on fields?
I’d consider that as a variation on “accept it without the mandatory in sdist requirements”. If that option is the consensus, I’d have thought we can discuss adding a recommended backend behaviour section.
OK, so the poll suggests people do like PEP 621 to want to keep trying to make it work, but drop the mandatory sdist inclusion/updating requirement. That’s fine by me so I will update the PEP accordingly (hopefully soon).
I’m fine with doing that, but I plan to be very clear that it’s totally optional and the details are acting as guidelines for build tools that choose to keep pyproject.toml up-to-date.
I think we should probably just be silent on the question of modifying pyproject.toml, as part of the build, or possibly mildly discourage it. Once we have standardized sdists, I feel like that sort of thing would be a complete anti-pattern, and I fully expect us to have something akin to standardized sdists well before a significant fraction of the ecosystem is using PEP 621.
Agreed. When I said that we can discuss this, it was only to note that was an option if people wanted to consider it. As far as I know, only @bernatgabor has suggested this. (I’m not personally that bothered).
I have now removed the sdist updating requirement and dropped all of the sdist suggestions as well. You will know when https://www.python.org/dev/peps/pep-0621/ is showing the updated copy when “Post-History” lists “24-Oct-2020” (the date that I’m writing this).
1. I would find it useful if the PEP showed the expected resulting core metadata for the example [project] table.
Is the following a good approximation?
Metadata-Version: 2.1
Name: spam
Version: 2020.0.0
Summary: Lovely Spam! Wonderful Spam!
Description: This project provides powerful math functions
|For example, you can use `sum()` to sum numbers:
|
|Example::
|
| >>> sum(1, 2)
| 3
|
Description-Content-Type: text/x-rst; charset=UTF-8
Requires-Python: >=3.8
License: This software may only be obtained by sending the
author a postcard, and then the user promises not
to redistribute it.
Keywords: egg,bacon,sausage,tomatoes,Lobster Thermidor
Author-email: hi@pradyunsg.me
Author: Tzu-Ping Chung
Maintainer-email: Brett Cannon <brett@python.org>
Classifier: Development Status :: 4 - Beta
Classifier: Programming Language :: Python
Requires-Dist: httpx
Requires-Dist: gidgethub[httpx]>4.0.0
Requires-Dist: django>2.1; os_name != 'nt'
Requires-Dist: django>2.0; os_name == 'nt'
Provides-Extra: test
Requires-Dist: pytest < 5.0.0; extra == 'test'
Requires-Dist: pytest-cov[all]; extra == 'test'
Project-URL: homepage, example.com
Project-URL: documentation, readthedocs.org
Project-URL: repository, github.com
Project-URL: changelog, github.com/me/spam/blob/master/CHANGELOG.md
2. The PEP seems a bit unclear on what should happen if multiple names (without email) are listed in authors and/or maintainers. Or seen from the other side, I find it unclear how multiple author names should be specified in core metadata (it is clearly specified how to add multiple emails though).
3. In the “Rejected Ideas” section these 2 points seem to contradict each other, or am I reading this wrong?
I have a question about the dynamic field. Apologies if this has been discussed before/elsewhere.
It says If the core metadata[1] specification lists a field as “Required”, then the metadata MUST specify the field statically or list it in dynamic (build back-ends MUST raise an error otherwise, i.e. it should not be possible for a required field to not be listed somehow in the [project] table).
Does this mean that in the case of back-end like Flit or setuptools_scm (which obtains the version from elsewhere than pyproject.toml), users would need to explicitly write dynamic=version ?
Or is it the case that, if sdist standardization goes the PKG-INFO route with a mechanism to achieve the same goal as dynamic, then dynamic will be removed from PEP 621 ?
This is not possible since an sdist must have a static version (it is also present in the sdist’s filename). I’d say the sdist standard should require that version field must be listed statically in PKG-INFO (or whatever we call the standardised sdist metadata file).
That’s not how I see it happening, no. The sdist metadata says that the build backend is reserving the right to generate the metadata later. The data in pyproject.toml says that the user is allowing the build backend to fill in that value.
Assuming I understand correctly that PEP 621 is becoming a UI for build back-end (with an enhanced PKG-INFO being the source of truth for sdists), this dynamic field sounds to me like an unnecessary burden placed on users.
Indeed if I’m using Flit or setuptools_scm I know that the back-end I use is going to generate the version. Version is just an example of course, this equally applies to any field that the back-end will compute.
Or is dynamic in PEP 621 caring for other use cases (such as optimizing dependency resolution of direct URLs that are not sdists) ?
The main purpose for dynamic is to distinguish between “field not present and will have a default value” and “field not present and will be inferred on build-time”. This is important for fields like dependency specification (Requires-Dist in metadata), because there’s a bunch of optimisations a tool can do when a package really just have no dependencies. If we don’t have dynamic, tools would need to build the package to find out that there really aren’t any dependencies.
The design decision then comes down to whether we must force users to explicitly specify dynamic = ... or dependencies = []. The dynamic design was chosen because it is far less common to havve dynamic metadata than default metadata.
My understanding is that PEP 621 is intended to act as a portable way of specifying metadata, not just as a standardised format. So is you need your dependencies to be calculated at wheel build time (in setuptools, which allows for this) then you say that dependencies is dynamic. If you later switch to flit, which cannot do that, then your project will fail to build because flit will say “Cannot work out dependencies dynamically”. Similarly, if you use flit and determine the version dynamically, you have to say so, so that when you switch to setuptools, which it can say “I don’t know how to determine the version”.
Personally, I’m not convinced that switching build systems is a common use case, but it was definitely one of the drivers for the design.
Yes, this. It’s optimised for moving pyproject.toml to a different build backend (well, “optimised” is a bit strong - let’s say it’s taking the requirements of that use case into consideration )
Thanks Paul, I understand the back-end portability use case for dynamic. I had not considered that.
It could be valuable to mention it in the PEP.
TBH, I feel the burden on users and back-end authors is not worth the benefit.
FWIW, I have a use case for a build back-end for Odoo addons where most of the metadata comes from another source. In that case the dynamic field will force me to opt-out of PEP 621 for that back-end.
@sbidoul From an implementation (and new user) standpoint, I don’t see a way around dynamic. If the user wants to hard code a field there needs to be a way to override backend behavior and the lack of a field shouldn’t implicitly allow the backend to fill it.
)