On 29 January 2014 22:50, David Cournapeau 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 comment earlier
On Jan 30, 2014, at 12:33 AM, Evgeny Sazhin 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 major
>>
On Jan 29, 2014, at 11:50 PM, Tres Seaver 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 this is undefi
>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 imp
On Jan 29, 2014, at 11:50 PM, Tres Seaver 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 this is undefi
On Jan 29, 2014, at 8:50 PM, Tres Seaver 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 this is undefin
-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 n
On Jan 29, 2014, at 11:17 PM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin wrote:
>
>>
>> On Jan 29, 2014, at 10:49 PM, Donald Stufft wrote:
>>
>>>
>>> On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin wrote:
>>>
>
> Wheel is a package format. Packages are for
On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin wrote:
>
> On Jan 29, 2014, at 10:49 PM, Donald Stufft wrote:
>
>>
>> On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin wrote:
>>
Wheel is a package format. Packages are for transmitting and installing
bits. If you want to make some ki
On Jan 29, 2014, at 10:49 PM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin 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 b
On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin 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.
>>
>
>
>
> 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.
>
I didn’t say anything about self-unpacking executable. Egg alr
On Jan 29, 2014, at 6:34 PM, Evgeny Sazhin 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 the wheel
On Jan 29, 2014, at 9:50 AM, Evgeny Sazhin wrote:
>
>
>
> On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip 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 going on, with the title "Using
I'm sorry for possible dup, but for whatever reason i don't see this
email reaching the list, so i'm resending.
On Wed, Jan 29, 2014 at 12:50 PM, Evgeny Sazhin wrote:
>
>
>
>
> On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip wrote:
>>
>> > Does it mean that it actually makes sense to look into tha
On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip 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 going on, with the title "Using Wheel with
> zipimport",
> which is relevant to this question, an
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 executable_proj
On Jan 29, 2014, at 2:59 PM, Nick Coghlan 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
> 2. Break zipimp
On Jan 29, 2014, at 5:59 PM, Nick Coghlan 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
> 2. Break zipimp
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 zi
On Wed, Jan 29, 2014 at 10:52 PM, Donald Stufft 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 things like MKL
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 wrote:
>
>
>
> On Wed, Jan 29, 2014 at 10:27 PM, Chris Barker wrote:
> On Wed, Jan 29, 2014 at 2:04 PM, David Cou
On Wed, Jan 29, 2014 at 10:27 PM, Chris Barker wrote:
> On Wed, Jan 29, 2014 at 2:04 PM, David Cournapeau wrote:
>
>> 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 ca
On Jan 29, 2014, at 5:24 PM, Nick Coghlan 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 around the
> PEP sh
On Wed, Jan 29, 2014 at 2:04 PM, David Cournapeau wrote:
> 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 decomposition,
> but want to
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 featur
On Sun, Jan 26, 2014 at 12:29 AM, Nick Coghlan 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
> installed, so you wil
On 30 Jan 2014 07:50, "Greg Ewing" 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 we
>> wanted th
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 format'
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 wrote:
>
>
> On Wed, 29/1
On 30/01/14 00:59, Nick Coghlan wrote:
> On 29 January 2014 23:48, Donald Stufft 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:
> https://mail.python.org
On Wed, 29/1/14, Paul Moore 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 hasn't been a mainstrea
On 29 January 2014 14:25, Vinay Sajip 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 not depend on runtime s
On Jan 29, 2014, at 10:00 AM, Vinay Sajip wrote:
>
>
> On Wed, 29/1/14, Donald Stufft 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-
On 29 January 2014 13:31, Donald Stufft 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 in a thread
> 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
> ch
On Wed, 29/1/14, Daniel Holth wrote:
> Here are some of the problems with eggs that I tried to solve:
[snipped]
Right, and the wheel design has addressed those issues. I suppose
what I was after was the kinds of problems that would arise from the
imp
On Wed, 29/1/14, Donald Stufft 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 or Egg) that c
On 30 Jan 2014 00:28, "Vinay Sajip" 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 consenting adult w
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 Wed, Jan 29, 2014 at 9:40 AM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 9:25 AM, Vinay Sajip 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 th
On Wed, 29/1/14, Donald Stufft 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 the code be s
On Jan 29, 2014, at 9:25 AM, Vinay Sajip 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 consenting adult
> 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 *exa
On Jan 29, 2014, at 8:59 AM, Vinay Sajip wrote:
> Nick Coghlan 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
On 29 January 2014 23:59, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>> goes further than the current EXTENSIONS approach - this proposal
>> would be akin to *requiring* an empty EXTENSIONS file, and/or the
>> setuptools zip_safe flag in order to allow mounting of even the pure
>> Pytho
On Jan 29, 2014, at 8:59 AM, Nick Coghlan wrote:
> On 29 January 2014 23:48, Donald Stufft 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:
> htt
> 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 extension
On 29 January 2014 13:41, Evgeny Sazhin 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 NumPy, SQL Alchemy
On Tue, Jan 28, 2014 at 10:41 PM, Evgeny Sazhin wrote:
>
> On Jan 28, 2014, at 9:54 PM, Daniel Holth wrote:
>
>> On Tue, Jan 28, 2014 at 8:04 PM, Evgeny Sazhin wrote:
>>> Hi,
>>>
>>> I saw that people from this list are responsible for Wheel related PEP.
>>> I'm comparatively new to the python p
Nick Coghlan 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 isn't e
On 29 January 2014 23:48, Donald Stufft 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:
https://mail.python.org/pipermail/distutils-sig/2012-September/0189
On 29 January 2014 23:34, Donald Stufft 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
believe wheels are
On Wed, Jan 29, 2014 at 8:31 AM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 8:10 AM, Paul Moore wrote:
>
>> On 29 January 2014 12:58, Nick Coghlan 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.
>>
>
On Jan 29, 2014, at 8:46 AM, Nick Coghlan wrote:
> On 29 January 2014 23:34, Donald Stufft 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
On Wed, Jan 29, 2014 at 8:44 AM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 8:43 AM, Daniel Holth wrote:
>
>> On Wed, Jan 29, 2014 at 8:31 AM, Donald Stufft wrote:
>>>
>>> On Jan 29, 2014, at 8:10 AM, Paul Moore wrote:
>>>
On 29 January 2014 12:58, Nick Coghlan wrote:
> You can camp
On Jan 29, 2014, at 8:43 AM, Daniel Holth wrote:
> On Wed, Jan 29, 2014 at 8:31 AM, Donald Stufft wrote:
>>
>> On Jan 29, 2014, at 8:10 AM, Paul Moore wrote:
>>
>>> On 29 January 2014 12:58, Nick Coghlan wrote:
You can campaign to deprecate that feature *if* we ever want to make a
On Jan 29, 2014, at 8:34 AM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 8:32 AM, Nick Coghlan wrote:
>
>> On 29 January 2014 23:31, Donald Stufft wrote:
>>>
>>> Here's Paul explicitly mentioning that Wheels being used with zip import is
>>> an incidental benefit and not a core feature.
>>
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 th
On Jan 28, 2014, at 9:54 PM, Daniel Holth wrote:
> On Tue, Jan 28, 2014 at 8:04 PM, Evgeny Sazhin 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
>> understanding the recommended wa
On Jan 29, 2014, at 8:32 AM, Nick Coghlan wrote:
> On 29 January 2014 23:31, Donald Stufft 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
On Jan 29, 2014, at 8:31 AM, Nick Coghlan wrote:
> On 29 January 2014 23:16, Donald Stufft 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? Can
>> you
>> point to a sin
On 29 January 2014 23:31, Donald Stufft 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 we discussed
On 29 January 2014 23:16, Donald Stufft 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? Can you
> point to a single line in the PEP that supports this besides the ones you've
On Jan 29, 2014, at 8:10 AM, Paul Moore wrote:
> On 29 January 2014 12:58, Nick Coghlan 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.
On Jan 29, 2014, at 8:17 AM, Nick Coghlan wrote:
> On 29 January 2014 23:10, Paul Moore wrote:
>> On 29 January 2014 12:58, Nick Coghlan 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 th
On 29 January 2014 23:10, Paul Moore wrote:
> On 29 January 2014 12:58, Nick Coghlan 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.
On Jan 29, 2014, at 8:14 AM, Nick Coghlan wrote:
> On 29 January 2014 22:57, Donald Stufft 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
On 29 January 2014 22:57, Donald Stufft 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 everyone has a chan
On 29 January 2014 12:58, Nick Coghlan 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 should be a "special
On Jan 29, 2014, at 7:58 AM, Nick Coghlan wrote:
> On 29 January 2014 21:50, Donald Stufft 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 shoul
On 29 January 2014 21:50, Donald Stufft 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 to the PEP re
On Jan 29, 2014, at 7:43 AM, Paul Moore wrote:
> On 29 January 2014 12:18, Donald Stufft 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
On 29 January 2014 12:18, Donald Stufft 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 of it as cla
On Jan 29, 2014, at 6:59 AM, Paul Moore wrote:
> On 29 January 2014 11:41, Donald Stufft wrote:
>>
>> On Jan 29, 2014, at 4:23 AM, Paul Moore 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 proj
On 29 January 2014 11:41, Donald Stufft wrote:
>
> On Jan 29, 2014, at 4:23 AM, Paul Moore 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 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 distributi
On Wed, Jan 29, 2014 at 3:41 AM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 4:23 AM, Paul Moore 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 fi
On Jan 29, 2014, at 6:47 AM, Donald Stufft wrote:
>
> On Jan 29, 2014, at 2:32 AM, Nick Coghlan 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 t
On Jan 29, 2014, at 2:32 AM, Nick Coghlan 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* potentially inexperie
On 29 January 2014 10:36, Vinay Sajip wrote:
> Paul Moore 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 zipimpor
On Jan 29, 2014, at 4:23 AM, Paul Moore 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 world using the
On 24 January 2014 06:18, Vinay Sajip 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.
>> In most case
On 29 January 2014 20:36, Vinay Sajip wrote:
> Paul Moore 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 Paul's concern is with anything
Paul Moore 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 C extens
On 29 January 2014 04:14, Vinay Sajip 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.
My specific concerns
On 29 January 2014 05:52, Donald Stufft 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 " feature here
On Sat, Jan 25, 2014 at 4:29 PM, Nick Coghlan 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
> 64 (both relea
Donald Stufft 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 them
On 29 January 2014 18:06, Paul Moore wrote:
> On 29 January 2014 05:06, Chris Barker 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 of the stack as well -- just sayin'
On 29 January 2014 05:06, Chris Barker 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 of the stack as well -- just sayin'
Agreed - my main use for NumPy is with Pandas fo
91 matches
Mail list logo
