This is very similar to what Debian calls "Recommends". A recommends
relationship is like a soft version of Depends -- if A recommends B, then
installing A will by default pull in B, but if B is unavailable or the user
asks that B not be installed, then that's OK (rather then being an error
like
On 15 December 2015 at 16:37, Michael Merickel wrote:
> It seems to me this would be easily accomplished by declaring some extras
> like "cext" as default-included and if the install fails someone can depend on
> "sqlalchemy[-cext]". The UI isn't quite as nice as your proposal
On Tue, Dec 15, 2015 at 9:20 AM, Paul Moore wrote:
> This is more a thought for something that would be good to include in
> Metadata 2.0, or whatever ends up taking its place.
>
> I was installing some packages on a new PC, that doesn't have a
> compiler. As I did so, I
On Tue, Dec 15, 2015 at 12:30 PM, Paul Moore wrote:
> I guess you're saying add [speedups] as a way of requesting a rebuild?
> But if the build fails, would that remove sqlalchemy, or leave the
> existing build there? (I'd hope the latter).
>
Well in this world of wheels we
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.
http://thread.gmane.org/gmane.comp.python.distutils.devel/21020
On Tue, Dec 15, 2015 at 12:59 PM, Robert Collins
On 15 December 2015 at 18:40, Michael Merickel wrote:
>
> Well in this world of wheels we aren't necessarily building anything right..
> so there's no "rebuild" or "build". We are just unzipping a bdist and some
> optional deps. I've seen in the past that a recommended way of
Hello everyone,
the talk about the sqlalchemy feature extra got me thinking
what if i could specify extras that where installed by default, but
users could opt out
a concrete example i have in mind is the default set of pytest plugins
i would like to be able to externalize legacy support
On 16 December 2015 at 07:30, Paul Moore wrote:
> On 15 December 2015 at 16:37, Michael Merickel wrote:
>> It seems to me this would be easily accomplished by declaring some extras
>> like "cext" as default-included and if the install fails someone can
On Mon, Dec 14, 2015 at 11:00 PM, Kevin Glisson wrote:
> I believe this might have something to do with the fact that I took over
> the namespace from a different package. My package has never successfully
> been publish to pypi so I am not working about breaking anyone's
Hi,
I have a development workflow question I was wondering if people on
this list had a recommended solution for.
Say you're working on a web application that you deploy using a
requirements.txt file. And say you have a set of "abstract
dependencies" that your application depends on.
What are
You might find
https://github.com/openstack/requirements/blob/master/openstack_requirements/cmds/generate.py
useful.
Basically it takes a open-ended (or partly so) set of requirements,
expressed as in requirements.txt format, and generates an exact-match
requirements.txt file as output.
So,
> On Dec 15, 2015, at 8:56 PM, Chris Jerdonek wrote:
>
> Hi,
>
> I have a development workflow question I was wondering if people on
> this list had a recommended solution for.
>
> Say you're working on a web application that you deploy using a
> requirements.txt
I've tried several things including bumps, the release always changes, but
I've never successfully been able to add any files.
On Tue, Dec 15, 2015, 2:13 AM Ionel Cristian Mărieș
wrote:
>
> On Mon, Dec 14, 2015 at 11:00 PM, Kevin Glisson
> wrote:
>
>> I
This is more a thought for something that would be good to include in
Metadata 2.0, or whatever ends up taking its place.
I was installing some packages on a new PC, that doesn't have a
compiler. As I did so, I noticed a dependency on sqlalchemy fly by,
and I thought "oh, that's going to fail",
14 matches
Mail list logo