On Mon, Dec 2, 2013 at 5:22 AM, Nick Coghlan wrote:
> And the conda folks are working on playing nice with virtualenv - I don't
> we'll see a similar offer from Microsoft for MSI any time soon :)
>
nice to know...
> > > a single organisation. Pip (when used normally) communicates with PyPI
> > >
On 3 Dec 2013 09:03, "Paul Moore" wrote:
>
> On 2 December 2013 22:26, Nick Coghlan wrote:
> >>Whether solving the Unix
> >> issues is worth it is the Unix users' call - I'll help solve the
> >> issues, if they choose to, but I won't support abandoning the existing
> >> Windows solution just beca
> I'm not sure about the conda -> wheel direction, but "pip install conda &&
> conda init" mostly works already if you're in a virtualenv that owns its
> copy of Python
>
ok, I just tried conda in a throw-away altinstall of py2.7.
I was thinking I would have to "conda create" new isolated environme
On 3 Dec 2013 08:17, "Marcus Smith" wrote:
>
>
>>>
>>> publication of curated stacks when the conda folks already have one,
>>
>> so, I see the index: http://repo.continuum.io/pkgs/index.html
>> Is they a way to contribute to this index yet? or is that what would
need to be worked out.
>
>
> pro
On 2 December 2013 22:26, Nick Coghlan wrote:
>>Whether solving the Unix
>> issues is worth it is the Unix users' call - I'll help solve the
>> issues, if they choose to, but I won't support abandoning the existing
>> Windows solution just because it can't be extended to cater for Unix
>> as well.
On 3 Dec 2013 00:19, "Paul Moore" wrote:
>
> On 2 December 2013 13:38, Tres Seaver wrote:
> > On 12/01/2013 06:38 PM, Paul Moore wrote:
> >> I understand that things are different in the Unix world, but to be
> >> blunt why should Windows users care?
> >
> > You're kidding, right? 90% or more of
> publication of curated stacks when the conda folks already have one,
>>
> so, I see the index: http://repo.continuum.io/pkgs/index.html
> Is they a way to contribute to this index yet? or is that what would need
> to be worked out.
>
probably a dumb question, but would it be possible to conver
On 3 Dec 2013 02:01, "Imran M Yousuf" wrote:
>
> Thanks for the suggestion Paul. Wheel structures exactly as I want it
> to be, but I see it does not generate the entry point scripts; any
> idea how to get them to work?
Those are platform dependent, so the installer generates them at install
time
On Tue, Nov 19, 2013 at 1:56 PM, Kura wrote:
> Hey guys
>
> I'm trying to dig in to how setuptools/distutils reads the
> [install_]requires keyword and how requirements.txt is handled.
>
> I've tried running setup.py --requires but get an empty response back, this
> also fails when using >=x.x,<=x
On Mon, Dec 2, 2013 at 9:14 AM, Michael Jansen wrote:
> Hi
>
>
>
> I am currently working on the cobbler (http://cobblerd.org) setup.py and
> trying to improve it. It currently is only capable of installing to /usr for
> several reasons. Since i would like to have virtualenv support when running
>
> In the conda build guide, the yaml spec files reference dependencies by
> name/version (and the type of conda environment you're in will determine
> the rest)
>
> http://docs.continuum.io/conda/build.html#specifying-versions-in-requirements
> Where does the hash come in? what do you mean?
>
e.g
> hash based dependencies
>
In the conda build guide, the yaml spec files reference dependencies by
name/version (and the type of conda environment you're in will determine
the rest)
http://docs.continuum.io/conda/build.html#specifying-versions-in-requirements
Where does the hash come in? what do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/2013 12:23 PM, Vinay Sajip wrote:
> On Mon, 2/12/13, Tres Seaver wrote:
>
>> The issue is combinatorial explosion in the compatibility tag
>> space. There is basically zero chance that even Linux users (even
>> RedHat users across RHEL ver
On Mon, 2/12/13, Tres Seaver wrote:
> The issue is combinatorial explosion in the compatibility tag space.
> There is basically zero chance that even Linux users (even RedHat
> users across RHEL version) would benefit from pre-built binary
> wheels (as opposed to packages from their distribut
Thanks for the suggestion Paul. Wheel structures exactly as I want it
to be, but I see it does not generate the entry point scripts; any
idea how to get them to work?
Thank you,
Imran
On Mon, Dec 2, 2013 at 7:59 PM, Paul Moore wrote:
> On 2 December 2013 07:53, Imran M Yousuf wrote:
>> Hi,
>>
Damn me! Thanks Paul, yes the script does have it in the data folder.
Thank you,
Imran
On Mon, Dec 2, 2013 at 9:32 PM, Paul Moore wrote:
> On 2 December 2013 15:28, Imran M Yousuf wrote:
>> Thanks for the suggestion Paul. Wheel structures exactly as I want it
>> to be, but I see it does not ge
On 2 December 2013 15:28, Imran M Yousuf wrote:
> Thanks for the suggestion Paul. Wheel structures exactly as I want it
> to be, but I see it does not generate the entry point scripts; any
> idea how to get them to work?
The scripts should be generated when you install the wheel (with pip
1.5, wh
On 2 December 2013 14:19, Oscar Benjamin wrote:
> Basically if
> 1) There is at least one single consistent set of built wheels for
> Windows/OSX for any popular set of binary-interdependent packages.
> 2) A way to automatically detect incompatibilities and to
> automatically find compatible built
On 2 December 2013 13:54, Paul Moore wrote:
>
> If the named projects provided Windows binaries, then there would be
> no issue with Christoph's stuff. But AFAIK, there is no place I can
> get binary builds of matplotlib *except* from Christoph. And lxml
> provides limited sets of binaries - there
On 2 December 2013 13:38, Tres Seaver wrote:
> On 12/01/2013 06:38 PM, Paul Moore wrote:
>> I understand that things are different in the Unix world, but to be
>> blunt why should Windows users care?
>
> You're kidding, right? 90% or more of the reason for wheels in the first
> place is because W
Hi
I am currently working on the cobbler (http://cobblerd.org) setup.py and trying
to improve it. It
currently is only capable of installing to /usr for several reasons. Since i
would like to have
virtualenv support when running it i am trying to change that. While doing that
i managed to mee
On 2 December 2013 07:53, Imran M Yousuf wrote:
> Hi,
>
> I am new to setuptools. I am using it to build and package a project
> of mine. Currently if I execute `python setup.py bdist` it generates a
> tarball with all files located in paths
> './abs/path/to/project/bin/[entry points]' and
> './ab
On 2 December 2013 13:22, Nick Coghlan wrote:
>> As a quick sanity check question - what is the long-term advice for
>> Christoph (and others like him)? Continue distributing wininst
>> installers? Move to wheels? Move to conda packages? Do whatever you
>> want, we don't care? We're supposedly pus
On Mon, Dec 2, 2013 at 12:38 AM, Paul Moore wrote:
> On 1 December 2013 22:17, Nick Coghlan wrote:
>
> > For example, I installed Nikola into a virtualenv last night. That
> required
> > installing the development headers for libxml2 and libxslt, but the error
> > that tells you that is a C comp
Hi,
I am new to setuptools. I am using it to build and package a project
of mine. Currently if I execute `python setup.py bdist` it generates a
tarball with all files located in paths
'./abs/path/to/project/bin/[entry points]' and
'./abs/path/to/project/lib/python-2.7/site-packages/[rest of the
so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/01/2013 06:38 PM, Paul Moore wrote:
> I understand that things are different in the Unix world, but to be
> blunt why should Windows users care?
You're kidding, right? 90% or more of the reason for wheels in the first
place is because Windows u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/01/2013 05:17 PM, Nick Coghlan wrote:
> I see conda as existing at a similar level to apt and yum from a
> packaging point of view, with zc.buildout as a DIY equivalent at that
> level.
FTR: zc.buildout does nothing to insulate you from the nee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/01/2013 05:07 PM, Vinay Sajip wrote:
> On Sun, 1/12/13, Paul Moore wrote:
>
>> If the issue is simply around defining compatibility tags that
>> better describe the various environments around, then let's just
>> get on with that - we're going
On 2 Dec 2013 21:57, "Paul Moore" wrote:
>
> On 2 December 2013 10:45, Oscar Benjamin
wrote:
> > Nick's proposal is basically incompatible with allowing Cristoph
> > Gohlke to use pip and wheels. Christoph provides a bewildering array
> > of installers for prebuilt packages that are interchangeab
On 2 December 2013 10:45, Oscar Benjamin wrote:
> Nick's proposal is basically incompatible with allowing Cristoph
> Gohlke to use pip and wheels. Christoph provides a bewildering array
> of installers for prebuilt packages that are interchangeable with
> other builds at the level of Python code b
On 2 December 2013 09:19, Paul Moore wrote:
> On 2 December 2013 07:31, Nick Coghlan wrote:
>> The only problem I want to take off the table is the one where
>> multiple wheel files try to share a dynamically linked external binary
>> dependency.
>
> OK. Thanks for the clarification.
>
> Can I su
On 2 December 2013 07:31, Nick Coghlan wrote:
> The only problem I want to take off the table is the one where
> multiple wheel files try to share a dynamically linked external binary
> dependency.
OK. Thanks for the clarification.
Can I suggest that we need to be very careful how any recommenda
32 matches
Mail list logo
