On 13 May 2014 08:03, "Paul Moore" <p.f.mo...@gmail.com> wrote: > The current approach is to solve 90% of the problem by noting that > nearly all projects don't take advantage of any of the (usually > undocumented) flexibility that distutils allows. This has thus far > been a great success, in terms of getting people on board with the new > tools and technologies. The problem is that it does nothing for that > remaining 10%[1] > > We're now at a point where people like MAL, who are in that 10%, are > getting excluded and we don't have a good answer for them. That's a > big problem - particularly as the people in question are quite often > those to whom we owe a lot of the progress that distutils gave us (I > remember the pre-distutils world, and it *SUCKED*). I wish we had an > answer here. I'm particularly worried that some proportion of the 10% > may be complex in-house environments that we'll never hear about till > we break them horribly. But I don't know what we can do. We need to be > able to move forwards, and the lack of encapsulation in distutils > means we will break things when we do. > > Now I'm depressed...
Note that this problem is specifically why the metadata 2.0 extension design now has the concept of mandatory extensions - so we can later define an installation hook system (along the lines of RPMs triggers), and have installers that don't understand the relevant extension fall back to installing directly from source. We should make that "fall back to running 'setup.py install' directly if you don't understand a metadata extension in the wheel file" aspect explicit, but either a metabuild system spec or the revision of the wheel spec that adds metadata 2.0 support would likely be the right place for that, rather than having it directly in the metadata 2.0 details (on the other hand, it may also make sense to include as an example use case for the attribute in the PEP 426 explanatory notes). Cheers, Nick. > > Paul > > [1] 95% of all statistics quoted on the internet were made up on the spot. > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig