<div dir="ltr">FWIW here is the original SQLAlchemy thread from last year that I was talking about when suggesting the external dependency on a sqlalchemy-cext package.<div><br></div><div><a href="http://thread.gmane.org/gmane.comp.python.distutils.devel/21020">http://thread.gmane.org/gmane.comp.python.distutils.devel/21020</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 15, 2015 at 12:59 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 16 December 2015 at 07:30, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
> On 15 December 2015 at 16:37, Michael Merickel <<a href="mailto:mmericke@gmail.com">mmericke@gmail.com</a>> wrote:<br>
>> It seems to me this would be easily accomplished by declaring some extras<br>
>> like "cext" as default-included and if the install fails someone can depend on<br>
>> "sqlalchemy[-cext]". The UI isn't quite as nice as your proposal but reuses<br>
>> existing machinery.<br>
><br>
> Hmm, so sqlalchemy says it provides an extra "speedups" (or "cext") by<br>
> default, checks for a compiler, and removes that extra from what's<br>
> installed if there's no compiler available?<br>
><br>
> Not sure why anyone would depend on sqlalchemy[-cext] - they should<br>
> always depend on sqlalchemy, as there's no functional difference<br>
> between with speedups and without. And the user should never specify<br>
> the extra, all they do is install a compiler and rebuild.<br>
><br>
>>> What I'd like to be able to do:<br>
>>><br>
>>> 1. pip install sqlalchemy works, but shows a warning "optional feature<br>
>>> speedups not installed - no C compiler"<br>
>><br>
>> Extras wouldn't give a nice message like this. The install would fail and<br>
>> the user would have to guess as to why and then opt out of the default<br>
>> extra. Perhaps some better error message could be displayed if the package<br>
>> failed to install and had a default extra included to show how to opt out.<br>
><br>
> But the install doesn't fail - it succeeds and works fine, just<br>
> without some speedups. That's exactly what I want. In my particular<br>
> case I was installing csvkit which depends on sqlalchemy. It doesn't<br>
> (nor should it) say that it doesn't need the speedups, nor should I<br>
> have to manually locate the specific dependency (from a list of many)<br>
> and install it by hand before my install works. The current behaviour<br>
> (pip install csvkit -> a working csvkit with no issues) is perfect.<br>
><br>
> But if I later want to use SQLalchemy independently, or I find that a<br>
> particular usage of csvkit is too slow, I want to know that there's a<br>
> speedups module I can get by downloading a binary build or installing<br>
> my own compiler. And I want to be able to install it transparently.<br>
><br>
>>> 3. A command to reinstall the currently installed version with new options<br>
>>>    pip install --add-options sqlalchemy[speedups]<br>
>>>    (Note that a plain pip install doesn't do this, as it won't<br>
>>> reinstall. And --upgrade or --ignore-installed will install newer<br>
>>> versions).<br>
>><br>
>> This should be done by simply reinstalling the package via "pip install<br>
>> sqlalchemy[speedups]". I doubt you need an extra --add-options flag to<br>
>> compete with extras.<br>
><br>
> I guess you're saying add [speedups] as a way of requesting a rebuild?<br>
> But if the build fails, would that remove sqlalchemy, or leave the<br>
> existing build there? (I'd hope the latter).<br>
><br>
> Won't that say "sqlalchemy is already installed"? (I've never used<br>
> extras with pip, so I don't know). Also what if there's been a newer<br>
> version of sqlalchemy released? Won't it get that one?<br>
><br>
> I specifically want to say here "just reinstall the exact version I<br>
> have here, but try again to include optional stuff that I didn't get<br>
> last time". (In practice I don't really care much if I upgrade, so<br>
> --upgrade or --ignore-installed is probably fine in reality).<br>
><br>
> Anyway, all of this requires people to implement it, in pip and build<br>
> tools, as well as projects to adopt it. So it's not really important<br>
> that the details get thrashed out right now, just that we establish<br>
> whether it's a practical scenario to support, and get a feel for how<br>
> much work it would be for projects to adopt it (if it's too much, they<br>
> won't, and the feature will end up unused). So the fact that extras<br>
> might be able to support this is the main point here, not the details<br>
> of how it would work - so thanks.<br>
<br>
</div></div>I'm not sure that extras would support it cleanly.<br>
<br>
I agree that it is a common use case; in general I'd say<br>
<br>
1) consumers (users and depending projects) shouldn't need to know<br>
about accelerators<br>
2) some environments will need to be able to exclude them [known to build badly]<br>
3) some consumers will need to be able to mandate them [either using<br>
an acclerator only feature, or their thing is known to be infeasible<br>
without them]<br>
4) there needs to be a means to get accelerators if they didn't<br>
install first time around<br>
5) projects with accelerators shouldn't be forced to split the<br>
accelerators into separate projects<br>
<br>
Some issues with reusing extras are:<br>
 - extras refer to things in the dependency graph, but as<br>
distributions are the installable things and the graph nodes are<br>
distributions, foo[fast] is - in widespread deployment - entirely and<br>
only a list of additional distributions.<br>
 - there's no concept of 'default extra', and there is no clear path<br>
for bringing it in compatibly, at least so far<br>
 - we haven't worked through the ui implications about which end of<br>
the relation this should be configured: should consumers be specifying<br>
them, or providers?<br>
 - negative operators on extras are as yet undefined, and due to the<br>
dependencies of an install being a graph, not a tree, a naive<br>
definition is likely very hard to use IMO<br>
<br>
Recommends and suggests are an interesting way of modelling this, and<br>
its possible we don't need an exclude relation- rather users should<br>
blacklist them globally in the target environment somehow, which would<br>
contain that partcular complexity.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hpe.com">rbtcollins@hpe.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span></blockquote></div><br></div>