Some packaging systems do not have the same 1:1 source : distribution relationship that is so prominent in the distutils model. This should probably change long term.
On Sat, Mar 8, 2014 at 9:53 AM, Michael Bayer <mike...@zzzcomputing.com> wrote: > > On Mar 8, 2014, at 9:19 AM, Jason R. Coombs <jar...@jaraco.com> wrote: > > > > From: Distutils-SIG > [mailto:distutils-sig-bounces+jaraco=jaraco....@python.org] On Behalf Of > Marcus Smith > Sent: Thursday, 06 March, 2014 16:16 > To: DistUtils mailing list > Subject: Re: [Distutils] tourist here, with a dumb RTFM question > > > > > > On Thu, Mar 6, 2014 at 10:37 AM, Michael Bayer <mike...@zzzcomputing.com> > wrote: > > > 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'm new to understanding setuptools "Feature" myself, so don't crank too > much, if I get anything wrong. > > afaik, it means something like: > > SQLAlchemy-X.Y.tar.gz > SQLAlchemy-cext-X.Y.tar.gz > > i.e. isolating the feature into a separate project. > > and then instead of having the handy "--with-cext" option, it has to be > "pip install SQLAlchemy[SQLAlchemy-cext] > > PJ, Jason: can you clarify what the alternative is supposed to look like? > > I'm new to understanding Features as well, but based on PJ's post, I would > agree with Marcus here. This is how I interpreted the use of extras to > supersede Features. I see a lot of advantages to this approach over > build-time selection. Because it decouples the main project from the > C-extension speedups, it gives the installer control over what behavior is > present. It also gives deployment tools visibility over what capability is > present (with features, it's harder to tell if the C-extension speedups are > present; with extras, one can query pkg_resources). > > > > If there's an easy way to do this from setup.py it wouldn't be so bad: > > python setup.py --without-cext sdist upload > > python setup.py sdist upload > > but it still seems kind of strange to deliver the exact same source files > with some flag somewhere different? I'd assume that flag is in setup.cfg, > which means, it's a setup.py flag in any case! not to mention its still > needed as part of the "sdist" and other commands to build dists. > > I think the issue of "you should have individual projects on pypi with > different options to make life easier for builders" is orthogonal to > "setup.py should or should not support flags". > > > > > > > > > > > > _______________________________________________ > 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 > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
