On 30 October 2014 10:29, Richard Jones rich...@python.org wrote:
It could get quite messy, without consensus. I figured custom tags would be
a more local thing.
Yep, that's what I would suggest - keep it off PyPI for now, but
provide some way to actually try the concept in real environments.
On 29 Oct 2014 01:02, David Cournapeau courn...@gmail.com wrote:
Practically speaking, there is no such a thing as ABI on Linux: even if
you somehow managed to deal with glibc, you would then need to deal with
fortran ABI, then with C++ ABI, etc... Dealing with this at the python
level is simply
This is the kind of direction we're also exploring for Fedora EPEL:
setting up a distro specific devpi instance so we can automatically publish
distro compatible wheel files, as well as separating the distro level
licencing and preliminary security review step from the step of repackaging
in
I've always thought people might like to have a custom platform tag or
otherwise customize the supported list in a configuration file loaded
by pep425tags. Then you could create wheels called
somewheel-4.0-py33-none-30caa8a209d6.whl (choose your own random
string). Only a pip with a matching
yes, I'm partial to a solution like this prior to wheel 2.0 (that I imagine
would support additional/custom tags)
On Wed, Oct 29, 2014 at 1:46 PM, Daniel Holth dho...@gmail.com wrote:
I've always thought people might like to have a custom platform tag or
otherwise customize the supported list
On 30 Oct 2014 07:20, Marcus Smith qwc...@gmail.com wrote:
yes, I'm partial to a solution like this prior to wheel 2.0 (that I
imagine would support additional/custom tags)
+1 for being able to add additional custom platform tags in the file naming
convention from me as well. As Marcus noted
On Oct 29, 2014, at 7:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 Oct 2014 07:20, Marcus Smith qwc...@gmail.com
mailto:qwc...@gmail.com wrote:
yes, I'm partial to a solution like this prior to wheel 2.0 (that I imagine
would support additional/custom tags)
+1 for being
On Wed, Oct 29, 2014 at 8:17 PM, Donald Stufft don...@stufft.io wrote:
On Oct 29, 2014, at 7:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 Oct 2014 07:20, Marcus Smith qwc...@gmail.com wrote:
yes, I'm partial to a solution like this prior to wheel 2.0 (that I
imagine would support
It could get quite messy, without consensus. I figured custom tags would be
a more local thing.
On 30 October 2014 11:17, Donald Stufft don...@stufft.io wrote:
On Oct 29, 2014, at 7:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 Oct 2014 07:20, Marcus Smith qwc...@gmail.com wrote:
Hi there,
Following up on
https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility.
How should we deal with incompatibility of dynamically linked libraries?
Doing pip wheel numpy on a Linux 64bit machine results in , which is
linked dynamically against the GLIBC version installed on the
On 28 October 2014 10:13, Matthias Hafner hafne...@gmail.com wrote:
(in reverse order, easiest to hardest :-))
Why does that work on MacOS, btw? Are all library versions fixed there for
one version of OSX?
I believe (I'm not 100% sure as I'm a Windows user not an OSX user)
that PyPI only
On Tue, Oct 28, 2014 at 10:13 AM, Matthias Hafner hafne...@gmail.com
wrote:
Hi there,
Following up on
https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility.
How should we deal with incompatibility of dynamically linked libraries?
Doing pip wheel numpy on a Linux 64bit machine
2014-10-28 15:04 GMT+01:00 Paul Moore p.f.mo...@gmail.com:
On 28 October 2014 10:13, Matthias Hafner hafne...@gmail.com wrote:
(in reverse order, easiest to hardest :-))
Why does that work on MacOS, btw? Are all library versions fixed there for
one version of OSX?
I believe (I'm not 100%
Here is a test matrix that checks binary compatibility of OSX wheels
for many projects of the SciPy stack:
https://github.com/MacPython/scipy-stack-osx-testing
--
Olivier
___
Distutils-SIG maillist - Distutils-SIG@python.org
2014-10-28 16:22 GMT+01:00 Olivier Grisel olivier.gri...@ensta.org:
Here is a test matrix that checks binary compatibility of OSX wheels
for many projects of the SciPy stack:
https://github.com/MacPython/scipy-stack-osx-testing
And here are the results:
On 28.10.2014 11:13, Matthias Hafner wrote:
Hi there,
Following up on
https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility.
How should we deal with incompatibility of dynamically linked libraries?
Doing pip wheel numpy on a Linux 64bit machine results in , which is
linked
In article
cafve7k4u7l4+8n3u72eher4fa8m-fcanv0q75bhm1aalfma...@mail.gmail.com,
Olivier Grisel olivier.gri...@ensta.org wrote:
Homebrew-installed Python and the system Python that comes by default
on OSX are binary compatible with wheels generated with Python from
the official OSX installer
17 matches
Mail list logo
