[Distutils] tourist here, with a dumb RTFM question

[Daniel Holth]

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_mp at zzzcomputing.com> wrote:
>
> On Mar 8, 2014, at 9:19 AM, Jason R. Coombs <jaraco at jaraco.com> wrote:
>
>
>
> From: Distutils-SIG
> [mailto:distutils-sig-bounces+jaraco=jaraco.com at 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_mp at zzzcomputing.com>
> wrote:
>
>
> On Mar 6, 2014, at 1:07 PM, Daniel Holth <dholth at 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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>