Idea: Introduce/standardize project development scripts

[ofek (Ofek Lev)]

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 my agreement with @bernatgabor’s point of view:

@ofek

@bernatgabor

@CAM-Gerlach

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

@bernatgabor

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 he is expressing the reality of what people are asking with examples, and then again elsewhere, and then right below that 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 because there is no maintainer/tooling buy-in for technical reasons:

@brettcannon

@bernatgabor

This sounds to me like you want to standardize the test runners’ interface, not define generic task runners.

I asked that already 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. 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 but I want to be more explicit now that I’ve had time to think. Anything that is not literally Brett’s proposal I would likely be against and never choose to implement in Hatch.