> From: Donald Stufft
> I think I am against this.
>
> Part of the beauty of Wheel is that it is simply a package format. This means
> it does not need to concern itself with situations that Egg had to which bloat
> the spec and make it harder to implement. I feel like tacking too much onto
> th
On 25 August 2013 23:14, PJ Eby wrote:
> > Unless I'm missing something, I suspect that this over-counts the number
> of
> > people using multi-version, in the sense that many (the majority?) of
> > wrapper scripts using multi-version do not actually need to,because the
> > users never install mo
On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore wrote:
> On 25 August 2013 23:14, PJ Eby wrote:
>>
>> > Unless I'm missing something, I suspect that this over-counts the number
>> > of
>> > people using multi-version, in the sense that many (the majority?) of
>> > wrapper scripts using multi-version
On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore wrote:
> On 25 August 2013 23:14, PJ Eby wrote:
>> Thus, you don't have to know you have multiple versions installed; it
>> can trivially happen by way of dependencies you aren't paying
>> attention to. The more things you install, the more likely it i
PJ Eby telecommunity.com> writes:
>
> That is all easy_install does: add a naming convention for the
> directories, and automate the sys.path manipulation.
>
> Buildout does the same thing, it just writes the sys.path manipulation
> into the scripts statically, instead of using pkg_resources at
On Aug 26, 2013, at 10:33 AM, PJ Eby wrote:
> On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore wrote:
>> On 25 August 2013 23:14, PJ Eby wrote:
>>> Thus, you don't have to know you have multiple versions installed; it
>>> can trivially happen by way of dependencies you aren't paying
>>> attention t
Just to add a bit more "FUD" ;-)
I do a lot of packaging things up with py2app, py2exe, etc. -- I find
I often want to be able to give folks "one thing" that they can
install and run, and I'd rather they don't even need to know it's
built with python.
A while back, when I was doing this with a w
Hi,
I'm one of the developers of www.pyinstaller.org, a tool for creating
stand-alone executables.
We need to reliable detect if a package is a namespace package (nspkg).
For each namespace, we need to add an empty fake-module into our
executable to keep the import mechanism working. This has to
Carl, Eby,
Thanks for taking time to suggest various alternatives. Considering that the
deployment hosts are identical in every as[ect, the approach of moving
virtualenv's with packages pip-installed at build time appears the simplest,
low-overhead approach that can be implemented without hacki
On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft wrote:
> There is always a cost. In this case mostly in complexity and start up time.
>
> As you mentioned originally the cost to multi version support was the need
> to use a require() function and when people complained about that you
> added the .
On Mon, Aug 26, 2013 at 1:48 PM, Chris Barker - NOAA Federal
wrote:
> Just to add a bit more "FUD" ;-)
>
> i.e. if a user has only needs one version of a given package
> installed, lets not have much overhead there to support that, and
> let's not require much run-time support at all.
Nick's
PJE:
Thanks for the clarification: based on that: +1 on Nick's proposal.
Chris
On Aug 26, 2013, at 1:41 PM, PJ Eby wrote:
> On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft wrote:
>> There is always a cost. In this case mostly in complexity and start up time.
>>
>> As you mentioned originally
On Mon, Aug 26, 2013 at 6:36 AM, Hartmut Goebel
wrote:
> Hi,
>
> I'm one of the developers of www.pyinstaller.org, a tool for creating
> stand-alone executables.
>
> We need to reliable detect if a package is a namespace package (nspkg).
> For each namespace, we need to add an empty fake-module in
On Aug 26, 2013, at 4:40 PM, PJ Eby wrote:
> On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft wrote:
>> There is always a cost. In this case mostly in complexity and start up time.
>>
>> As you mentioned originally the cost to multi version support was the need
>> to use a require() function an
I think we're actually all in violent agreement at this point. I mainly
wanted to ensure we had a sensible path forward for this capability that
could be made backwards compatible with pkg_resources without too much
difficulty :)
To summarise:
* default versions will continue to work as they do n
On Mon, Aug 26, 2013 at 5:59 PM, Donald Stufft wrote:
> I think you're confused. The only comments I see in this thread are people
> doing
> due diligence to ensure that Nick's proposal *didn't* include the parts of
> setuptools
> that we felt were incurring a cost against people not using the f
Daniel Holth wrote:
I would like to see some consideration given to what Ruby and npm do,
which is to place what we are calling dists into a special directory
that only contains dists /somedir/distname-1.0/... rather than placing
them as specially named objects on the normal search path.
What a
17 matches
Mail list logo
