On 4 September 2013 11:30, Donald Stufft <don...@stufft.io> wrote: > On Sep 4, 2013, at 6:21 AM, "M.-A. Lemburg" <m...@egenix.com> wrote: > >> I quite like the idea of using setup.py as high level >> interface to a package for installers to use, since that >> avoids having to dig into the details built into the >> setup.py code (and whether it uses setuptools, bento, >> custom code, etc.). > > I like it as a temporary solution that is backwards compatible with the old > tooling but I don't think it should be the interface going into the future.
I don't think anyone has even begun to discuss what such an "interface for the future" should be. In principle that would be nice, but on a pure practicality point of view documenting current practice makes a lot of sense. It also offers the option of having a spec that backward compatibility adapters could use to allow current tools to work with the "interface for the future" when that arrives. > All of this completely skirts the fact that any change to distutils would only > be available in 3.4+ or 3.5+ which makes it's value practically zero. It's > not like other modules in the library where you can reasonably expect > someone to have a backport installed if you need to use the new features. > Setuptools has already gone through the long process of getting everyone > to get it installed, why would we want to go through that again for a system > that should eventually be deprecated entirely? I think you misunderstand at least what I am suggesting. You can, right now, write code in your setup.py that provides a bdist_wheel command, using pure distutils. (That's the "cmdclass" interface that MAL has mentioned). That would work on any version of Python with distutils, no matter how old. It's quite a lot of code, so you may want to split it out into a separate module, and you may then want to make that module available independently for other projects to use, but that's not actually relevant. It's essentially what setuptools already does, the only real difference is that setuptools actually modifies the extensibility methods of distutils rather than just using them. There may be some more complex areas where actual changes to distutils are required. That's precisely what I'd like to see established - if we knew what that "minimal API" was that setup.py had to provide, we'd be able to experiment to find out if we could provide it without distutils changes or not. [BTW, this is *precisely* the sort of debate that is non-productive if the mandate is to use setuptools. It's why I keep asking for clarity on the status of setuptools - do projects have the option of trying this sort of thing out and therefore asking for explanations of what they need to provide to support packaging tools, or is that option explicitly rejected and those projects need to import setup from setuptools and stop trying to implement their own version? Mandating setuptools would cut off the drain on time that is threads like this - at the cost of potentially alienating those people who still want to explore such options.] Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
