On Mar 6, 2014, at 1:07 PM, Daniel Holth <dho...@gmail.com> wrote: > pje said: > > The "Feature()" facility was never completely implemented or > supported, and even if it were, it should be deprecated now, as it > will not be compatible with the coming packaging systems based on PEP > 426. If you need separate features, use separate distributions and > "extras" instead.
wait, ok this is that thing. “separate distributions” means…. SQLAlchemy-0.9.3-nocext.tar.gz SQLAlchemy-0.9.3-cext.tar.gz ?? I think that’s what it means. OK, not sure if I have to say this but that would be…OK very very unworkable. A Python package distribution is a *source distribution*. That suggests that one need to package up separate source distributions in order to specify an option, is… OK very very unworkable. (note by “very very unworkable” I mean “list of hyperboles I had to backspace out because that’s not why I’m here”). If a package has three flags, now there need to be *eight source distros*? Really? On the plus side, I just used math. how does one even maintain this in source control? Do I have setup.py.nocext, setup.py.cext, maintain a copy of 99% the same code in each, then rename them when I do “python setup.py sdist” (since sdist doesn’t take command line options either!!) ? The suggestion is completely inappropriate. I don’t know the metadata format in pep426 well enough to comment (as I wanted to use it one day and found that it seemed to still be pretty much vapor), but I’ll reiterate: these are source distributions, not binaries or wheels or anything like that. A source distro has to build, and builds need options. A metadata format that purports to represent metadata about a source distribution and does not support flags is a broken metadata format. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
