[Distutils] A smaller step towards de-specializing setuptools/distutils

Donald Stufft donald at stufft.io
Thu Oct 29 16:03:08 EDT 2015


On October 29, 2015 at 3:40:04 PM, Daniel Holth (dholth at gmail.com) wrote:
> I find CLIs to be very difficult to implement, should I bootstrap require
> click? How does my bundled-in-sdist build system code generate executable
> wrappers for Windows? Plus on the command line all method signatures suck:
>  
> metadata(arguments: list of strings in any order)
> wheel(arguments: list of strings in any order)
>  
> It could be a module instead of a class but a method/function interface
> would have nice documented method signatures:
>  
> def wheel(target: string): ...
>  
> you'd copy the example into your new build system adapter, implement, and
> be done. Perhaps pip could also call more than one command per subprocess
> more easily if the need arose. If you want your def wheel() to shell out go
> ahead…

Sure, your build tool can require click, or it can use argparse or anything it wants. It’s just Python and you no longer need to worry about trying to defer imports, so it becomes just another Python script at that point.

Of course, since your build system can have it’s own dependencies now, if people really want a class based API like that it’d only take one person to make a wrapper that implements the CLI based build interface and layers on your build-with key. So if projects want to make a class based interface it’s pretty easy to make that possible. Ideally they’d use a custom section in the setup.cfg like:

[cli2class]
build-with = foobar:Whatever

Like I said before, it’s easy to add stuff, hard to take it away. If someone did that and it worked out well, we could then add official support for that and remove the need to have the shim package without breaking things for anyone who used the shim package. Having the current interface defined is still then useful for everyone else.

>  
> I could live without the entry points, it adds one line to setup.cfg in my
> strawman. But we are doomed to standardize setuptools-compatible entry
> points eventually.

I’m sure we will end up standardizing setuptools-compatible entry points at some point, but we don’t need to do that right now. Small incremental changes that enable things to move forward without locking us into supporting something that has been largely untested.


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA




More information about the Distutils-SIG mailing list