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
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 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 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
-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
-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 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
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
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 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
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 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
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 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 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
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
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,
>>
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
-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
> 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
> 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
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
>
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 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
> 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 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
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 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
> 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 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
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
> > >
32 matches
Mail list logo
