Are twine maintainers OK to have a `twine build` command?

[pradyunsg]

@pradyunsg looks at https://discuss.python.org/t/building-distributions-and-drawing-the-platypus/2062 and sighs.

Hey @pypa/twine-team!

Are y'all fine with twine growing a twine build command in the future? Do twine maintainers feel like twine build would be out of scope for the tool?

The relevant context is in the first post of the discussion that I've linked to above. That discussion quickly diverged from the topic of "how to expose build logic" to "what should a unified tool for Python packaging/development workflow look like", so most replies there are not relevant to the question I'm asking here.

If we'd be doing this, it'd be based on a shared implementation of the underlying build and install logic, that would be the result of refactoring "out" pip's existing build and install logic. This is something that I plan to be working on later this year, and I'm trying to figure out the direction that work should be headed.

Before someone asks, yes, I checked with my fellow pip maintainers -- there's a long on-going discussion within that group privately, about what's "in scope" for pip. It seems to me that we'd be concluding that a pip build would be out of scope, which is why I'm preempting that conclusion and checking here.

[jaraco]

This question interacts with the discussion in #160, but also pypa/pip#6041 and pypa/packaging-problems#219.

The short answer is "no": twine shouldn't have a build command until there's consensus on where that functionality should reside. That issue should be reconciled in pypa/packaging-problems#219. If the resolution there is that twine should host that functionality, then this project will enthusiastically adopt that responsibility.

[jaraco]

So many discussions still open. I just read through pypa/pip#6041, which led me back to your original reference. Please don't take my closure of this issue as authoritative or prejudiced. I encourage your work to try to find a solution to this user-facing workflow issue.

[pradyunsg]

there's consensus on where that functionality should reside.

Right, but for building that concensus, I think it'd be useful to know if the maintainers of twine even want to be responsible for supporting/maintaining this functionality -- which is the question I'm asking here.

[pradyunsg]

FWIW, I am aware that the question is intertwined with many other discussions happening in many locations -- I am actively involved in nearly all those venues of discussion and initiated some of them. #160 also links back to the d.p.o discussion I linked to above.

Anyway, I think what I'm asking here is much more scoped and independent of that. :)

If the resolution there is that twine should host that functionality, then this project will enthusiastically adopt that responsibility.

I'm gonna move ahead assuming that all @pypa/twine-maintainers agree with this, so please holler if you disagree.

I'm not gonna reopen this issue even though I have the permissions to do so, but other folks are welcome to do so if they disagree with this, and would like to discuss the specifics (of the question I've asked in this issue), in further detail.

[jaraco]

I think it'd be useful to know if the maintainers of twine even want to be responsible for supporting/maintaining this functionality.

I do believe I've answered that question; this project will enthusiastically support that need if that's the recommended approach. I welcome others on the project to chime in before closing.

[sigmavirus24]

For years I've had this on the horizon in my mind for twine. I don't have time to commit to writing it though or keeping up with all of the latest standards and such so I never volunteered it because twine's resources are already stretched thin

[sigmavirus24]

That is to say: As a user of twine, I've wanted a twine build for forever, I just haven't needed it enough to do it

[di]

In my experience, users tend to think of twine as "a tool for package publishers" and pip as "a tool for package installers". If the goal is to replace python setup.py ... (which IMO it should be) then I think regardless of the fact that pip needs this logic under the hood to do its job, twine should be the place where this API is exposed to users.

It seems to me that a library like pep517, which knows how to build PEP517/518 distributions, could and should be reused across both tools.

One other thing: I'm hesitant to call this command twine build as it's not clear to me how the creation of source distributions, which are by definition not built, would fall under this command. This area is already pretty confusing for users. Maybe the command should be something other than build, like:

• twine package source
• twine package wheel

[pradyunsg]

puts on bikeshedding hat with an evil smile

@di How about generate -- generating distributions?