On 29 January 2014 18:06, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 05:06, Chris Barker chris.bar...@noaa.gov wrote:
This isn't just for users of the SciPy Stack -- there are LOT of use-cases
for just numpy by itself. Not that I don't want folks to have easy access of
the rest
Donald Stufft donald at stufft.io writes:
1. That unpacking into the home directory is problematic because users
that run services often don’t have home directories. This you waved
away by saying that the home directory isn’t a required place, to
which Jim responded that unpacking
On Sat, Jan 25, 2014 at 4:29 PM, Nick Coghlan ncogh...@gmail.com wrote:
To put the but what if the user doesn't have SSE2 support? concern in
context, it should only affect Intel users with CPUs older than a Pentium 4
(released 2001), and AMD users with a CPU older than an Opteron or Athlon
On 29 January 2014 05:52, Donald Stufft don...@stufft.io wrote:
Which further shows that at the time it was cool that it worked but that
the weird failures being a reason that Wheel was an installation format.
Having cool features in a format is not a bad thing. Zip imports are
the cool
On 29 January 2014 04:14, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
When this topic came up before, I asked for specific failure modes which
were causing concern, but I never got a response IIRC.
From what I recall, the topic came up before in relation to distlib's
wheel mount functionality.
Paul Moore p.f.moore at gmail.com writes:
1. It does *not* just use the fact that wheels are importable. It goes
beyond that and *extracts* C extensions to make them importable, too.
That is a workaround for a known and accepted limitation of zipimport,
and as a workaround, it has issues. If
On 29 January 2014 20:36, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
You don't want it to be there, even if it might be useful to others,
just because it isn't useful to you? It's not as if distlib is forcing
that functionality on anyone.
I believe
On 24 January 2014 06:18, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
certainly mention the distlib implementations,
but also let's be clear if there is a pypa-recommend
tool that is user-facing (like pip), that is using those
parts of distlib.
On Jan 29, 2014, at 4:23 AM, Paul Moore p.f.mo...@gmail.com wrote:
As I recall, it was in the original version of the PEP/spec and it was
always an intended feature. The wheel file for the wheel project
itself is (deliberately) runnable as a zip file, so that you can
bootstrap into the wheel
On 29 January 2014 10:36, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
1. It does *not* just use the fact that wheels are importable. It goes
beyond that and *extracts* C extensions to make them importable, too.
That is a workaround for a known and
On Jan 29, 2014, at 2:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
All of those arguments are against *recommending* directly importing
from wheels. Yes, there are lots of problems with running directly
from a zip archive, which is why the fact that easy_install *actively
encourages*
On Jan 29, 2014, at 6:47 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 2:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
All of those arguments are against *recommending* directly importing
from wheels. Yes, there are lots of problems with running directly
from a zip
On Wed, Jan 29, 2014 at 3:41 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 4:23 AM, Paul Moore p.f.mo...@gmail.com wrote:
As I recall, it was in the original version of the PEP/spec and it was
always an intended feature. The wheel file for the wheel project
itself is
That doesn't really speak to the fact they were designed for that. If I read
that it looks like some commenting that they are importable (which as it stands
they are) and not someone calling it a supported feature of the format. It even
states that the format is designed primarily for
On 29 January 2014 11:41, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 4:23 AM, Paul Moore p.f.mo...@gmail.com wrote:
As I recall, it was in the original version of the PEP/spec and it was
always an intended feature. The wheel file for the wheel project
itself is (deliberately)
On Jan 29, 2014, at 6:59 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 11:41, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 4:23 AM, Paul Moore p.f.mo...@gmail.com wrote:
As I recall, it was in the original version of the PEP/spec and it was
always an intended
On 29 January 2014 12:18, Donald Stufft don...@stufft.io wrote:
But more importantly, while I'm against officially supporting importable
Wheels
because of various reasons, my biggest problem is that this was added in
without any chance for discussion.
Fair point. I'm sure Nick did just think
On Jan 29, 2014, at 7:43 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 12:18, Donald Stufft don...@stufft.io wrote:
But more importantly, while I'm against officially supporting importable
Wheels
because of various reasons, my biggest problem is that this was added in
On 29 January 2014 21:50, Donald Stufft don...@stufft.io wrote:
As a follow up, even if this becomes something we document and actually
support, then it should be done in the next version of Wheel when people
have the chance to discuss it. It should not be added ex post facto by
a committer
On Jan 29, 2014, at 7:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 21:50, Donald Stufft don...@stufft.io wrote:
As a follow up, even if this becomes something we document and actually
support, then it should be done in the next version of Wheel when people
have the
On 29 January 2014 12:58, Nick Coghlan ncogh...@gmail.com wrote:
You can campaign to deprecate that feature *if* we ever want to make a
change to the wheel format that is incompatible with it.
Note that virtualenv uses the ability to run wheels from sys.path. I
don't believe that virtualenv
On 29 January 2014 22:57, Donald Stufft don...@stufft.io wrote:
Also to be specific, what I believe should be done is that the change should
be
reverted, and if it is desired that Wheels officially support zip import then
in the
next version of the Wheel spec it should be added when
On Jan 29, 2014, at 8:14 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 22:57, Donald Stufft don...@stufft.io wrote:
Also to be specific, what I believe should be done is that the change should
be
reverted, and if it is desired that Wheels officially support zip import
then
On 29 January 2014 23:10, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 12:58, Nick Coghlan ncogh...@gmail.com wrote:
You can campaign to deprecate that feature *if* we ever want to make a
change to the wheel format that is incompatible with it.
Note that virtualenv uses the
On Jan 29, 2014, at 8:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 23:10, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 12:58, Nick Coghlan ncogh...@gmail.com wrote:
You can campaign to deprecate that feature *if* we ever want to make a
change to the wheel
On Jan 29, 2014, at 8:10 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 12:58, Nick Coghlan ncogh...@gmail.com wrote:
You can campaign to deprecate that feature *if* we ever want to make a
change to the wheel format that is incompatible with it.
Note that virtualenv uses the
On 29 January 2014 23:31, Donald Stufft don...@stufft.io wrote:
Here's Paul explicitly mentioning that Wheels being used with zip import is
an incidental benefit and not a core feature.
https://mail.python.org/pipermail/distutils-sig/2013-March/020379.html
Donald, I was *there*. I know what
On Jan 29, 2014, at 8:31 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 23:16, Donald Stufft don...@stufft.io wrote:
So basically even though the text of the PEP specifically points out that a
difference
of Wheel and Egg is that Eggs are importable it somehow supports that?
On Jan 29, 2014, at 8:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 23:31, Donald Stufft don...@stufft.io wrote:
Here's Paul explicitly mentioning that Wheels being used with zip import is
an incidental benefit and not a core feature.
On Jan 28, 2014, at 9:54 PM, Daniel Holth dho...@gmail.com wrote:
On Tue, Jan 28, 2014 at 8:04 PM, Evgeny Sazhin eug...@sazhin.us wrote:
Hi,
I saw that people from this list are responsible for Wheel related PEP.
I'm comparatively new to the python packaging and need some help
On the one hand, it's easy to see the allure of a zipimport-able format.
Grab a file, import it, use functionality straight away. It has an
attraction of self-containedness. On the other hand, python's dynamic
nature means that things are not as simple as Java jar's as Donald points
out. I agree
On Jan 29, 2014, at 8:34 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 8:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 23:31, Donald Stufft don...@stufft.io wrote:
Here's Paul explicitly mentioning that Wheels being used with zip import is
an
On Jan 29, 2014, at 8:43 AM, Daniel Holth dho...@gmail.com wrote:
On Wed, Jan 29, 2014 at 8:31 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 8:10 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 12:58, Nick Coghlan ncogh...@gmail.com wrote:
You can campaign to
On Wed, Jan 29, 2014 at 8:44 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 8:43 AM, Daniel Holth dho...@gmail.com wrote:
On Wed, Jan 29, 2014 at 8:31 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 8:10 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January
On Jan 29, 2014, at 8:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 23:34, Donald Stufft don...@stufft.io wrote:
If I'm wrong, then by all means show me where it was discussed so I can admit
I was wrong.
You have the burden of proof backwards there. You're the one
On Wed, Jan 29, 2014 at 8:31 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 8:10 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 12:58, Nick Coghlan ncogh...@gmail.com wrote:
You can campaign to deprecate that feature *if* we ever want to make a
change to the
On 29 January 2014 23:34, Donald Stufft don...@stufft.io wrote:
If I'm wrong, then by all means show me where it was discussed so I can admit
I was wrong.
You have the burden of proof backwards there. You're the one asking me
to break backwards compatibility, and to let people continue to
Nick Coghlan ncoghlan at gmail.com writes:
I believe Paul's concern is with anything that suggests that arbitrary
*third party* code can be run from wheel files, when the reality is
that it is fairly easy to accidentally write code that assumes it is
installed on the filesystem in a way that
On 29 January 2014 23:48, Donald Stufft don...@stufft.io wrote:
So what did you mean when you said We discussed it extensively before
PEP 427 was approved if you're now saying that it wasn't discussed.
Explicitly would be a better word:
On 29 January 2014 13:41, Evgeny Sazhin eug...@sazhin.us wrote:
I have no knowledge about c extensions scope, but i feel like it might be of
less importance then pure python packaging issues? Am I wrong?
Most interesting Python projects will end up with C dependencies
through things like
Does it mean that it actually makes sense to look into that
direction and make wheel usage closer to jar?
There is a parallel discussion going on, with the title Using Wheel with
zipimport,
which is relevant to this question, and other questions you raised (e.g. about
supporting C
On Jan 29, 2014, at 8:59 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 January 2014 23:48, Donald Stufft don...@stufft.io wrote:
So what did you mean when you said We discussed it extensively before
PEP 427 was approved if you're now saying that it wasn't discussed.
Explicitly would
It may be useful to understand that wheel has *political features* or
if you prefer *setting the defaults based on what we have learned from
eggs*. I don't recommend that they be zip-imported generally
but if you are a consenting adult who understands the caveats you
may do so.
What
On Jan 29, 2014, at 9:25 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
It may be useful to understand that wheel has *political features* or
if you prefer *setting the defaults based on what we have learned from
eggs*. I don't recommend that they be zip-imported generally
but if you are a
On Wed, 29/1/14, Donald Stufft don...@stufft.io wrote:
Mitre’s rules for CVEs are not entirely obvious to people who are not
familiar with them. Generally if the feature *can* be used securely or
there was no evidence that the author intended that
On Wed, Jan 29, 2014 at 9:40 AM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 9:25 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
It may be useful to understand that wheel has *political features* or
if you prefer *setting the defaults based on what we have learned from
Here are some of the problems with eggs that I tried to solve:
- Cannot be unzipped on top of each other due to the EGG-INFO
directory. Wheels repeat the package name in the dist-info directory
and are more like their installed layout, hopefully taking all the
mystery out of the format.
- The egg
On 30 Jan 2014 00:28, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
It may be useful to understand that wheel has *political features* or
if you prefer *setting the defaults based on what we have learned from
eggs*. I don't recommend that they be zip-imported generally
but if you are a
On Wed, 29/1/14, Donald Stufft don...@stufft.io wrote:
It’s hard to pin down because the failure modes of zipped
eggs are nebulous themselves.
For instance take pip. I just recently redid the get-pip.py
installer to use a zip file (not a Wheel
I went through this with Chris McDonough back when packaging was
dropped from 3.3, and he really helped me focus on what I found to be
the two closely related core problems:
- implicit sys.path manipulation
- installing as eggs by default
That was due to easy_install defaults being
chosen
On 29 January 2014 13:31, Donald Stufft don...@stufft.io wrote:
Here's Paul explicitly mentioning that Wheels being used with zip import is
an incidental benefit and not a core feature.
https://mail.python.org/pipermail/distutils-sig/2013-March/020379.html
That's quoted out of context. It was
On Jan 29, 2014, at 10:00 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
On Wed, 29/1/14, Donald Stufft don...@stufft.io wrote:
It’s hard to pin down because the failure modes of zipped
eggs are nebulous themselves.
For instance take pip. I
On 29 January 2014 14:25, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
What *else* have we learned from eggs?
That designing modules to support zipimport correctly is non-trivial.
And that assuming that things work unless told otherwise is a bad
default behaviour.
That packaging solutions should
On Wed, 29/1/14, Paul Moore p.f.mo...@gmail.com wrote:
That designing modules to support zipimport correctly is non-trivial.
It's not trivial, but it's not especially hard, either. Mostly, it's about
remembering to consider zipimport, since that
On 30/01/14 00:59, Nick Coghlan wrote:
On 29 January 2014 23:48, Donald Stufft don...@stufft.io wrote:
So what did you mean when you said We discussed it extensively before
PEP 427 was approved if you're now saying that it wasn't discussed.
Explicitly would be a better word:
btw, there's a stub in the PUG for Wheel vs Egg, if anyone wants to help
fill that out.
https://python-packaging-user-guide.readthedocs.org/en/latest/technical.html#wheel-vs-egg
On Wed, Jan 29, 2014 at 7:07 AM, Vinay Sajip vinay_sa...@yahoo.co.ukwrote:
Nick Coghlan wrote:
Otherwise we'd have to define a whole new format for something that
can be adequately handled by a wheel that meets certain restrictions,
and that would be pointless (we already have too many formats, and we
wanted the wheel format to offer a strict superset of the egg
On 30 Jan 2014 07:50, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Nick Coghlan wrote:
Otherwise we'd have to define a whole new format for something that
can be adequately handled by a wheel that meets certain restrictions,
and that would be pointless (we already have too many formats, and
On Sun, Jan 26, 2014 at 12:29 AM, Nick Coghlan ncogh...@gmail.com wrote:
Paul's position exactly mirrors my own - I an perfectly fine with the
recommended advice to scientific users continuing to be NumPy doesn't
officially support pip and virtualenv because of the way it is built and
I have clearly done a bad job so far of explaining the clarification in PEP
427, so here's a new attempt that relies solely on the PEP text and the way
the import system works, rather than the fact that the discussions around
the PEP show that the import system compatibility was a deliberate
On Wed, Jan 29, 2014 at 2:04 PM, David Cournapeau courn...@gmail.comwrote:
I think the SSE issue is a bit of a side discussion: most people who care
about performance already know how to install numpy. What we care about
here are people who don't care so much about fast eigenvalue
On Jan 29, 2014, at 5:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
I have clearly done a bad job so far of explaining the clarification in PEP
427, so here's a new attempt that relies solely on the PEP text and the way
the import system works, rather than the fact that the discussions
I don’t see any reason why SSE couldn’t be added as tags in the Wheel filename
fwiw.
That doesn’t help for things like MKL though.
On Jan 29, 2014, at 5:50 PM, David Cournapeau courn...@gmail.com wrote:
On Wed, Jan 29, 2014 at 10:27 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Wed,
But that's what I'm saying, there are only three ways to break this
behaviour:
1. Changing the wheel format in such a way that we drop support for being
able to install simple wheel files without a specialised installer
2. Break zipimport itself to explicitly disallow wheel files
3. Switch to a
On Wed, Jan 29, 2014 at 10:52 PM, Donald Stufft don...@stufft.io wrote:
I don’t see any reason why SSE couldn’t be added as tags in the Wheel
filename fwiw.
You still need to decide when to install what, but I would be interested in
talking more about that part.
That doesn’t help for
On Jan 29, 2014, at 5:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
But that's what I'm saying, there are only three ways to break this behaviour:
1. Changing the wheel format in such a way that we drop support for being
able to install simple wheel files without a specialised installer
On Jan 29, 2014, at 2:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
But that's what I'm saying, there are only three ways to break this behaviour:
1. Changing the wheel format in such a way that we drop support for being
able to install simple wheel files without a specialised installer
Guys,
I'm still unable to see my emails reaching the list for unknown reason...
Any ideas what can be the problem?
FWIW I have tested it by adding the same __main__.py i used for the
egg variant of the distribution
to the wheel root and specifying
$ PYTHONPATH=projectA.whl; python
On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip vinay_sa...@yahoo.co.ukwrote:
Does it mean that it actually makes sense to look into that
direction and make wheel usage closer to jar?
There is a parallel discussion going on, with the title Using Wheel with
zipimport,
which is relevant to
On Jan 29, 2014, at 9:50 AM, Evgeny Sazhin eug...@sazhin.us wrote:
On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Does it mean that it actually makes sense to look into that
direction and make wheel usage closer to jar?
There is a parallel discussion
On Jan 29, 2014, at 6:34 PM, Evgeny Sazhin eug...@sazhin.us wrote:
Guys,
I'm still unable to see my emails reaching the list for unknown reason...
Any ideas what can be the problem?
FWIW I have tested it by adding the same __main__.py i used for the
egg variant of the distribution
to
On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin eug...@sazhin.us wrote:
Wheel is a package format. Packages are for transmitting and installing
bits. If you want to make some kind of self-unpacking executable please do
it with something built for it. makeself is an excellent choice for these.
On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin eug...@sazhin.us wrote:
On Jan 29, 2014, at 10:49 PM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin eug...@sazhin.us wrote:
Wheel is a package format. Packages are for transmitting and installing
bits.
On Jan 29, 2014, at 11:17 PM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin eug...@sazhin.us wrote:
On Jan 29, 2014, at 10:49 PM, Donald Stufft don...@stufft.io wrote:
On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin eug...@sazhin.us wrote:
Wheel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2014 06:55 PM, Noah Kantrowitz wrote:
If you are going to document this, and it is not going to be
explicitly supported by the spec (it isn't), the _only_ logical thing
is to document that this is undefined behavior and while it works
On Jan 29, 2014, at 8:50 PM, Tres Seaver tsea...@palladion.com wrote:
Signed PGP part
On 01/29/2014 06:55 PM, Noah Kantrowitz wrote:
If you are going to document this, and it is not going to be
explicitly supported by the spec (it isn't), the _only_ logical thing
is to document that
On Jan 29, 2014, at 11:50 PM, Tres Seaver tsea...@palladion.com wrote:
Signed PGP part
On 01/29/2014 06:55 PM, Noah Kantrowitz wrote:
If you are going to document this, and it is not going to be
explicitly supported by the spec (it isn't), the _only_ logical thing
is to document that
Eh, I think both 1 and 3 are things that are possibly reasonable to happen and
they are both things that I've contemplated as things to bring forward in
using xz as an alternative compression format. Even if #1 would need a major
revision of Wheel to happen adding official support for zip import
On Jan 29, 2014, at 11:50 PM, Tres Seaver tsea...@palladion.com wrote:
Signed PGP part
On 01/29/2014 06:55 PM, Noah Kantrowitz wrote:
If you are going to document this, and it is not going to be
explicitly supported by the spec (it isn't), the _only_ logical thing
is to document that
On Jan 30, 2014, at 12:33 AM, Evgeny Sazhin eug...@sazhin.us wrote:
Eh, I think both 1 and 3 are things that are possibly reasonable to happen
and
they are both things that I've contemplated as things to bring forward in
using xz as an alternative compression format. Even if #1 would need a
On 29 January 2014 22:50, David Cournapeau courn...@gmail.com wrote:
i.e. it would be nice if anyone setup to build C extensions could just
build numpy.
This has always been possible, and if not, that's certainly considered as a
bug (I would be eager to fix).
I don't know if you saw my
81 matches
Mail list logo
