# Idea: Introduce/standardize project development scripts **URL:** \ **Category:** Standards\ **Created:** [October 9, 2024, 2:01pm UTC](https://discuss.python.org/t/idea-introduce-standardize-project-development-scripts/67194 "2024-10-09T14:01:53Z")\ **Posts on this page:** 1\ **Showing post:** 26
**Author:** ![ofek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ofek/32/1033_2.png) [@ofek](https://discuss.python.org/u/ofek)\ **Post date:** [October 17, 2024, 7:34pm UTC](https://discuss.python.org/t/idea-introduce-standardize-project-development-scripts/67194/26 "2024-10-17T19:34:45Z")
Quickly writing some notes because I don’t have much time. > [@steve.dower](#): > > Ultimately though, the problem isn’t having a nice implementation. It’s having something “official” so that people who want to use “standard” tools don’t have to make a choice (yes, I’m being a bit facetious, but after watching this play out for over ten years, I think not unfairly). We can invent as many nice tools as we like, but the demands for the One True Tool will continue until it exists, and if it happens to be weaker than all the rest, it won’t matter (though it’ll be a shame). I’m extremely against such proposals because what Steve says here is the actual issue. People aren’t asking, not really, for interoperability but rather a single tool to do environment management. This is an attempt to standardize an implementation and UX rather than what we have historically used standardization to do which is give more freedom to tools and by extension their users. I’ll [repost](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/49) my agreement with @bernatgabor’s point of view: > [@Providing a way to specify how to run tests (and docs?)](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/49): > > > [@Providing a way to specify how to run tests (and docs?)](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/46): > > > > > [@Providing a way to specify how to run tests (and docs?)](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/45): > > > > > > However, it runs into the issue discussed above—there’s conflation between two levels of the stack, where either a testing tool or a task runner may be invoked here. > > > > Hence why I don’t like it that much. If the user sets up a testing (or documentation) tool here it easily can fail downstream or on another machine because you never addressed all the other factors at play > > > [@Providing a way to specify how to run tests (and docs?)](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/46): > > > > I think it’s similarly important that whatever we come up can live together with task runners and not cannibalize it. It would be a bad place where some of your test setup/teardown logic is in the `tasks` section and the rest in `nox/tox` configuration files (ini, toml or python file). > > I completely agree with Bernát, perhaps in part due to both of us maintaining such a tool. > > I think what most posters in this conversation are missing is that `tox`, `hatch`, `nox`, etc. should **not** be thought of as task runners but rather as _environment managers_, which is totally different and far more complex. > > Through that lens, what seems to be happening here is distributions like Fedora & Conda want a universal way to map the config of such managers (since most projects use one) to their own build system’s format. > > As such, I’m quite against standardization on this one. Perhaps `tox` and the like could offer a command that outputs the JSON config of the `default` or `base` environment that distributions could consume and translate to their liking. [Here](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/51) he is expressing the reality of what people are asking with examples, and then again [elsewhere](https://discuss.python.org/t/a-new-pep-to-specify-dev-scripts-and-or-dev-scripts-providers-in-pyproject-toml/11457/6), and then [right below that](https://discuss.python.org/t/a-new-pep-to-specify-dev-scripts-and-or-dev-scripts-providers-in-pyproject-toml/11457/7) another maintainer of a different tool Poe expresses the infeasibility. > [@steve.dower](#): > > However, while wearing multiple of my hats (including IDE developer and security reviewer), I would _really_ like to see it be based around dedicated interfaces into those tools, rather than arbitrary commands. The concept of defining an interface for granular functionality (e.g. testing) has been [all but rejected](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/53) because there is no maintainer/tooling buy-in for technical reasons: > [@Providing a way to specify how to run tests (and docs?)](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/53): > > > [@Providing a way to specify how to run tests (and docs?)](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/51): > > > > This sounds to me like you want to standardize the test runners’ interface, not define generic task runners. > > [I asked that already](https://github.com/pytest-dev/pytest/discussions/9342) once and was swiftly shot down, so I’m explicitly not asking that. That comment from the maintainer I mentioned above expressed a similar idea to Bernát’s [here](https://discuss.python.org/t/providing-a-way-to-specify-how-to-run-tests-and-docs/15016/44). Basically, the only concrete way that makes sense (although I personally have doubts still) is to standardize interactions with runners i.e. the highest abstraction possible. I mention it in passing [here](https://discuss.python.org/t/projects-that-arent-meant-to-generate-a-wheel-and-pyproject-toml/29684/36) but I want to be more explicit now that I’ve had time to think. Anything that is not literally Brett’s [proposal](https://github.com/brettcannon/python-launcher/discussions/168) I would likely be against and never choose to implement in Hatch. --- _[View the full topic](https://discuss.python.org/t/idea-introduce-standardize-project-development-scripts/67194)._