I had a couple of thoughts while reading this proposal:
Is there demand from projects to mandate a specific environment management tool?
None of the projects I maintain or contribute to have particular requirements on the location of the environment or the tool[1] used to create this. Admittedly, most of those are fairly simple projects; but even the developer docs of some very complex projects like Airflow or NumPy are agnostic in both regards.
I’m aware that some development teams within companies standardise on a specific workflow & environment managers; but I have no idea whether they’d be interested in this at all—I’d guess they already have custom tooling (or MDM software or …) to enforce that anyway.
Without clear demand for such a [workflow] table in pyproject.toml, I don’t think the significant added complexity of adding such a table and the corresponding override mechanism (pyproject.local.toml, plus per-user and per-machine equivalents) is justified.
Supporting different types of environments (i.e. virtual and conda)
I see this as an important point; if the current approach in PEP 832 doesn’t allow for this (which is a discussion that I’ll put in the other thread), that would be a significant downside.
I’m thinking about how this would work for people using workflows where all environments are stored in a central folder. In that case, there probably won’t be a mapping of environments to projects. I guess conda could return a JSON listing of all environments (instead of “the environments for the project”); but would something similar work for all tools?
There’s one exception here—a particle physics software stack I’ve worked on, which required conda because it needed to integrate complex non-Python dependencies. ↩︎