Almost not at all actually. Hatch already supports doing just environments without defining the project table.
I will of course support that when it happens and my idea was actually the same as someone else in one of these threads in that the run table would be equivalent to the default environment and I would literally just remap config before processing.
Semantics are best left to the other thread so I won’t go into detail but I think this is not exactly correct. dev-dependencies are usually used for projects that are meant for distribution wherein the testing/development requirements are installed alongside the project. I am imagining the main use case of a run table being a project like a web app or ML/AI script would define its runtime requirements and entry point (a new field). Historically, such projects use only a lock file like requirements.txt.
Paul outlined a few cases for what it means to be a project that is not meant for distribution but I think that is the main one that we should be targeting.
Not true, it implemented a non-standardised format that was copied from pip-run. It’s close to PEP 722, because I deliberately wrote PEP 722 to reflect current practice - but pipx never implemented PEP 722.
Also, the pipx feature isn’t released yet, in any form.
And yet that’s not what PEP 723 script dependencies are. They aren’t a list of the tools needed when developing the script, they are what’s needed when running the script. Not all non-wheel projects even have a concept of “being run”, and for those that do, I can absolutely imagine that “run dependencies” and “dev dependencies” might be different things. (Think of a web application, whose run dependencies include things like Django, but whose dev dependencies include black and ruff).
Please see the “projects not intended to produce a wheel” discussion. There’s a lot of types of project that aren’t building wheels, and [run] is only really a good fit for a small proportion of them. I don’t think we should add [run] and then come back to the same discussion a few months later to look at some other type of project. That would be exactly the sort of churn packaging users have expressed frustration at.
I’ve yet to see a good argument for why a “projects not intended to produce wheels” PEP should only target some (or just one) of the many non-wheel use cases. Maybe there is an argument, but no-one has made it yet - people (myself included!) are mostly just assuming that their use case is “obviously” a key one that needs to be supported.
For what it’s worth, I’m about to (currently working on… there’s a lot of editing and quoting involved) about to make an argument for a new proposal in the “projects not intended to build a wheel” thread, whereby this [run] table would… just be the [project] table. In that world, it would only make sense to update PEP 723 accordingly as well.
I’ll need to politely disagree here. AFAIK, PEP authors or delegates have no authoritative power over what tools do (even for projects under the PyPA). I consider having an experimental implementation live beneficial for the PEP, and willing to amend the implementation if changes are made to it between now and when it becomes final.
However, I will remind you that we tend to operate on a concensus based collaborative model and this PEP has strong network effects on how it affects end users. Going against the broader concensus unilaterally means that our social model will break down and no longer work effectively.
There are strong risks here, because of the fact that it’s not provisionally approved, it’s conditionally approved. People will start relying on it and pipx might end up in the uncomfortable position of needing to yank out or maintain for quite a while, an implementation of a then-rejected PEP.
From the decision above:
Emphasis not mine. That condition is not resolved down to a True / False yet.
That said, it sounds like you’re OK with treating this as a non-backwards compatibl/experimental feature. If so, please consider clarifying this in the documentation and change log for the feature.
I considered suggesting that we mark the PEP as “Deferred” to reflect that we don’t want tools to implement it yet, but figured that would not be necessary as we all agreed that we’d be waiting here or, at least, mention it here before moving forward with it.
I think that’s a good change to make still since clearly the assumption that we’re all on the same page here about what the provisional means was not correct.
I think @brettcannon has said he’d be looking at modifying PEP 723 in the light of whatever happens with [run], rather than outright rejecting it if [run] doesn’t happen, which sounds more like provisional acceptance than conditional acceptance. But I think things are unclear at the moment however you interpret the decision.
Add to that the fact that I think it’s going to be some time before the issue over [run] is resolved - the dependency groups PEP doesn’t seem to fit with PEP 723 (at the very least, [run] in PEP 723 would need to be replaced with [dependency-groups] with a specially-named group) and the attention on dependency groups means no-one is really thinking about the wider “projects that don’t use pyproject.toml” side of things, or other aspects of [run] like requires-python.
I currently don’t have a feel for what would happen with PEP 723 if, for example, dependency groups were added with some of the “extra features” (filesystem paths as dependencies, editable installs) that the PEP is currently suggesting, and that was viewed by the community as enough to address the use cases for [run] - at least in the medium term.
I’m disappointed that the current situation leaves us with two incompatible ways of specifying script dependencies - pip-run with the pre-standardisation comment form[1] and pipx with the provisional PEP 723 format. That means that we’re actually in a worse situation now than before we started standardising things (when we had a de facto format supported by pip-run, with pipx support just awaiting a release). Hopefully this won’t last too long In the meantime, I guess I’ll just continue using pip-run as there’s no real incentive to change.
As well as the older __requires__ form, which now seems even less likely to be deprecated in favour of “the standard” any time soon. ↩︎
For me, the incentive to change would be that pipx is much more commonly used and popular than pip-run. It’s preinstalled into GitHub Actions environments and some default container images, and is already the recommended way to install tools such as Poetry, etc so to me there is a much easier sell to other developers to use a pipx-available solution.
Having support for python-version specification was a large part of why the first draft of dependency-groups had a table containing dependency-groups.
My plan was to propose that PEP 723 be amended to use a dependency group conventionally named run, and to place the python-requires field adjacent to the dependency-group table.
Let’s set aside, for the purpose of this thread, debates about dependency groups (735) as a specific solution. The point is that there are other shapes for effectively the same data which we might agree belong in pyproject.toml .
Suppose some spec is accepted which doesn’t match the data in 723. What is the plan here? If pipx wants to support PEP 723 *in it’s accepted form" in addition to some “legacy” format which was in a provisional version of the PEP, that… sort of works.
It’s not what I like, personally, as a user or maintainer though.
Perhaps most importantly, are we then going to face some argument that formalizing anything other than the data in 723 is a mistake because “that’s what pipx implements”?
Implementations are “free to do whatever they like”, but that doesn’t mean there’s no potential for them to do harm to active discussions.
FYI I plan to implement 723 in Hatch very soon and I share Bernát’s view in the linked issue:
[…] we had a conversation last year that we are heading to a place where we are accepting PEPs that are never implemented. To stop that going ahead, we would require new PEPs to have at least one implementation live before we accept it.
I think having functional implementations of a PEP (even as just a POC) can be helpful to confirm that the specification is sufficient. However, those implementations should be clearly marked as experimental and possibly subject to change.
While the response to the opened issue on pipx clearly states that it is, that showed up after the fact. The change log doesn’t indicate that the functionality is experimental or that the PEP hasn’t been fully accepted yet. The people that spend time here are aware of the context and current state. However, I wouldn’t expect that from the python community at large. Coming from the change log, I wouldn’t be surprised if people didn’t think to look at the “status” maker.
Support in Hatch won’t quite be as experimental as you say. If the PEP doesn’t get accepted then support will not be removed and if it does then the implementation will be changed to match the final state.
The key point for me is we find some mechanism for declaring dependencies in both PEP 723 and pyproject.toml that we are happy with. Dependency groups has gone a direction different from my initial proposal which included a solution, but that’s fine and if I have to do a PEP for e.g. a top-level dependencies/requires-python or [run] then I can if we view it as orthogonal enough to the dependency groups PEP.
I’m still thinking about it, hence my proposal that sparked PEP 735. I can wait until PEP 735 is finished to start that conversation or we can have it separately now.
I think Paul has said he doesn’t love the idea of a special group name, but I could be remembering wrong.
About this, would anyone here be upset if I continued with my plan to implement in Hatch? Users want this feature and I don’t think an implementation should be blocked on final acceptance.
That’s my concern, too. Although it’s mitigated by the fact that (a) PEP 723 is at least conditionally accepted, and (b) Brett has indicated that he intends to modify PEP 723 rather than reject it.
If I were a user of this feature in hatch, though, I would be a little annoyed if it was presented as not-experimental (as Ofek suggests) and yet it was still changed later when the final form of PEP 723 landed - or worse, it was removed if PEP 723 was rejected. I’m not going to be a user of this feature, though, and it’s Ofek’s call as to what his users will be happy with.
One thing I am becoming convinced of, though, is that any sort of provisional or conditional acceptance of packaging PEPs has a tendency to cause more trouble than it’s worth, and I, personally, will be avoiding doing that in the future.
In the meantime, I guess I’ll just continue using