builds proceed with zero configuration #2329
Comments
|
It should indeed work the same as any |
|
|
|
Can the legacy backend enforce that a setup.py file must exist? The language in PEP 517 seems to imply that the expectation is for the file to exist, in projects built with the legacy backend:
|
|
Moving further, can the non-legacy backend enforce that setup.py or setup.cfg exist? A source tree without either can be basically... well, anything. It could be a user's home directory or whatever. |
|
What about when PEP 621 support lands? I'd hope eventually you could configure setuptools (for pure Python, at least) entirely from pyproject.toml. For |
|
I think the
I think that language is at best ambiguous, but I read it as saying, "You can invoke It seems like a pretty niche situation, though, for someone to be relying on PEP 517 behavior but unwilling to create a well-formed |
|
Right now, an empty directory is a valid setuptools package if you use the PEP 517 backends. Surely, we don't want that to be the case? |
|
Note that the medium-term plan very much is to enforce PEP 517 by default, and this issue is one of the blockers to doing that. |
I'm saying this is a problem to be solved regardless of the It's not like we want a directory with just a
Assuming we fix #2799 (which is basically this bug, but not scoped to |
|
Nope, that's good enough. :) |
So |
|
No, since you are allowed to call setup.py in the classic backend, then a valid PEP 517 builder could do that. You must have either setup.py or pyproject.toml, and pip/build both artificially enforce that. |
Assuming this is true, then how is this issue a blocker for PEP 517 by default? I should point out that the Same with distutils
I believe this behavior is somewhat deliberate, to provide reasonable defaults and let the project evolve specific values as needed. Since this issue is specifically about Since this issue has a lot more context than #2799, I'm going to re-scope this issue to the larger issue at hand and close that one as duplicate. |
jaraco
changed the title
jaraco
added
enhancement
Needs Discussion
|
I've been thinking a lot lately how I'd like to build a backend that requires zero configuration. We already see demonstrations of backends that derive metadata and configuration from existing sources:
I can imagine a world where a backend could derive reasonable defaults for metadata for a basic package from other common sources:
Such a backend would limit the need for boilerplate and templates and provide a streamlined experience for new and experienced users. In such a world, there is no required metadata. I suspect that's the principle that Setuptools and distutils were going for when they allowed building an empty directory. That is, if you build a degenerate project, you get a degenerate distribution. Another situation where this project finds value in accepting empty values is in the test suite. The test suite doesn't need to bother itself with creating a full-fledged distribution, but can create a distribution that exercises only the relevant aspects under test. Making any fields hard-required leads to requiring boilerplate values throughout the test suite, adding distraction and possible confusion ("was the value added for a purpose or to satisfy constraints"). To that end, I'm reluctant to require any metadata. I'm not even sure it's viable to require metadata when plugins are able to supply that metadata (such as setuptools_scm does for I'd like to explore more the failure modes that led to this discussion. In particular:
Can you explain more about the problems that occur other than the surprise that it succeeds? |
|
That any arbitrary directory on the file system is a valid setuptools package by this definition. Create an empty directory. Run pip install --use-pep517 on that directory. Notice that setuptools will happily create a package out of that. This means that passing the wrong path to pip (however you do that — a typo, an environment variable that expanded wrong etc) will result in setuptools zipping everything up. It also blurs the boundary of what a package is. PEP 517 explicitly declares there are two kinds - setup.py based and pyproject.toml based. Currently, setuptools doesn’t enforce either constraint. While I’m sure there’s certainly space for innovation and experimentation for zero configuration build backends, I highly encourage you to not try taking setuptools down that route. There are significant backwards compatibility constraints here, and it’s much better for that sort of innovation and experimentation to happen in a separate build backend IMO. |
|
FWIW, pip isn’t enforcing setup.py or pyproject.toml to exist. If you’d prefer that pip enforces that instead of setuptools, then… all good, this issue blocks nothing and there’s nothing actionable here. |
|
According to Henry and my experience, pip does enforce it: Same with I'm an enthusiastic +1 to making |
I can't really tell from the core metadata spec, but I was under the impression that at least I don't know how much more of it is required, but I think it would be fair for us to say that, at the very least, when generating package metadata, the required fields must be specified somehow. I went through and added It is definitely worth it, IMO, for the
The way I was considering this, and I think the way I've implemented it, was that we should enforce this as late in the process as possible. If we do it that way, any values supplied by a plugin would count as supplied values and the package would build just fine. |
|
|
FWIW, name is required in PEP 621. Also, I think it's fine to not specify name / version, etc, immediately, but by the time you are ready to make the output, if nothing has added it, it doesn't seem to make sense to build without name and versions, since they are part of the output file name. |
|
I don't disagree that name and version are required. I'm just saying that it's plausible, even possibly desirable, that it's not the user's responsibility to supply those, but that the build tool could supply those, perhaps using default values or inferring the values from better data. For example, 0 is a perfectly reasonable default version, especially for a project where a version is never needed. And a name of 'UNKNOWN', while a little awkward, is justifiable for the same reason. I don't feel strongly about it, and I do think 'UNKNOWN' probably should go, and that the system should error if no suitable name can be determined. On the other hand, a default version of 0 seems right to me and I can imagine lots of scenarios where that behavior would be useful (imagine a private environment where a suite of libraries are always built/installed from source and the version is unimportant to the design). |
My proposal was that we should validate these things as the last thing we do before generating a distribution. I think we can agree that we don't support a scenario where these things are supported after the artifact is generated, so I think our positions are not in conflict.
I feel like this is a rare enough scenario (and "oops I forgot to specify a version number" a common enough scenario) that we can impose upon people who don't care about version numbers to just specify a hard-coded version or specify some plugin that supplies one, no? |
Following up the discussion in pypa#2887 and pypa#2329, it seems that setuptools is moving towards more automatic discovery features. PackageFinder and PEP420PackageFinder are fundamental pieces of this puzzle and grouping together them togheter with the code implementing these new discovery features make a lot of sense.
How about using a warning here + changing the default version to something more obvious (and/or unique at every run). I believe that by adding a local segment, at least PyPI would reject the upload, so the chances of this kind of distribution to be made publicly available by mistake would drop. |
|
The problem is that setuptools is generally and increasingly used as a part of an automated workflow (e.g. pip install), and generating anything without an explicit error makes logical errors difficult to spot, even with a warning emitted in the middle of the process, when you’re inspecting only the final product of that entire workflow. |
|
That is an interesting point to analyse. What precisely the error/problem that would be important to avoid/spot? From a pragmatic point of view, I was supposing that the main problem here is having 2 distributions with the same nominal version ( For this problem, forcing the user to hard-code a version number will not help a lot, since in a future build the user can forget to bump it. Indeed, in this scenario proposal 2 (see bellow) helps more to avoid errors. Summary of the current behaviour and proposals (so far) for missing version. a) Current behaviour: setuptools considers version = 0, when it is not provided |
|
Add a |
|
I'm inclined to stick with the current behavior. There's value in not requiring these metadata values to be supplied in cases where the metadata is unimportant (tests, for one). The default values supplied are good defaults (UNKNOWN for name, 0 for version). The pip/build controls already provide good guardrails on ensuring the basic assumptions are met. I'd similarly like the validation to work in a layered approach, where the basic building blocks are lenient, allowing for degenerate behavior, but where specific workflows (such as building for release) enable more complex behaviors such as validations. Any solution for this should be holistic and not bolt the behavior on. It should probably coordinate with the config validation and the default metadata values. We can explore these options more readily once the distutils merge is complete. In the meantime, the issue, as reported is working as intended. |
|
So the validation PR was merged without actually hooking the validation logic onto anything or have I misunderstood? Meaning that setuptools will continue to build dists out of thin air.
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
…On Sunday, January 30th, 2022 at 00:32, Jason R. Coombs ***@***.***> wrote:
I'm inclined to stick with the current behavior. There's value in not requiring these metadata values to be supplied in cases where the metadata is unimportant (tests, for one). The default values supplied are good defaults (UNKNOWN for name, 0 for version). The pip/build controls already provide good guardrails on ensuring the basic assumptions are met.
I'd similarly like the validation to work in a layered approach, where the basic building blocks are lenient, allowing for degenerate behavior, but where specific workflows (such as building for release) enable more complex behaviors such as validations.
Any solution for this should be holistic and not bolt the behavior on. It should probably coordinate with the config validation and the default metadata values. We can explore these options more readily once the distutils merge is complete.
In the meantime, the issue, as reported is working as intended.
—
Reply to this email directly, [view it on GitHub](#2329 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHNRFWDUUKKETO2UR4HHGNTUYRTJTANCNFSM4P7OVQFQ).
Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Yes, that's right. I kept the code because I thought it might prove useful to have at some point, but you make a good point - it's probably not worth keeping that uncalled functionality around.
Correct. And after thinking about this more, I'm confident this approach is the right one. After all, there are already protections against building a dist out of an empty directory in the higher level build tools. Setuptools is a lower-level build tool, where direct invocation of Moreover, there is already some metadata validation that happens as part of the config processing as well as other stages in the development process (invoking build, invoking twine, uploading to pypi). Since there's value in supporting a degenerate distribution and there are complications with adding that constraint and because it's a long-held expectation, I'd like to keep it for now. The concern about the potential I'd like to explore the possibility of removing the default UNKNOWN values, an exploration which may likely lead to a failure on no name, but I'd like to see that as a larger design and probably after the distutils merge is complete. |
Following up the discussion in pypa#2887 and pypa#2329, it seems that setuptools is moving towards more automatic discovery features. PackageFinder and PEP420PackageFinder are fundamental pieces of this puzzle and grouping together them togheter with the code implementing these new discovery features make a lot of sense.
Following up the discussion in pypa#2887 and pypa#2329, it seems that setuptools is moving towards more automatic discovery features. PackageFinder and PEP420PackageFinder are fundamental pieces of this puzzle and grouping together them togheter with the code implementing these new discovery features make a lot of sense.
|
I'm a bit saddened to see this closed as no-action.
I'd argue this is a significantly worse experience than: if you build a degenerate project, you get an error telling you where you went wrong. I still feel that adding a clear failure mode that "you're missing a name and/or version" instead of a default
No stage contains protections against 0.0.0 versions. Only PyPI rejects I don't think that any level of tooling other than setuptools itself should hold protections for this. |
Following up the discussion in pypa#2887 and pypa#2329, it seems that setuptools is moving towards more automatic discovery features. PackageFinder and PEP420PackageFinder are fundamental pieces of this puzzle and grouping together them togheter with the code implementing these new discovery features make a lot of sense.
Following up the discussion in pypa#2887 and pypa#2329, it seems that setuptools is moving towards more automatic discovery features. PackageFinder and PEP420PackageFinder are fundamental pieces of this puzzle and grouping together them togheter with the code implementing these new discovery features make a lot of sense.
Hello, my understanding is that the
build_meta:__legacy__backend should behave likepython setup.py ...calls.However, I've realized that it proceeds fine without any
setup.py/setup.cfgfiles:This might be a problem in scripted environments. I would have expect an error here. Is this behavior deliberate or accidental?
The text was updated successfully, but these errors were encountered: