From: Donald Stufft don...@stufft.io
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
On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 August 2013 23:14, PJ Eby p...@telecommunity.com 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
On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 August 2013 23:14, PJ Eby p...@telecommunity.com 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
PJ Eby pje at 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 p...@telecommunity.com wrote:
On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 August 2013 23:14, PJ Eby p...@telecommunity.com wrote:
Thus, you don't have to know you have multiple versions installed; it
can trivially happen
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 web
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
On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft don...@stufft.io 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
PJE:
Thanks for the clarification: based on that: +1 on Nick's proposal.
Chris
On Aug 26, 2013, at 1:41 PM, PJ Eby p...@telecommunity.com wrote:
On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft don...@stufft.io wrote:
There is always a cost. In this case mostly in complexity and start up
On Aug 26, 2013, at 4:40 PM, PJ Eby p...@telecommunity.com wrote:
On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft don...@stufft.io 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
On Mon, Aug 26, 2013 at 5:59 PM, Donald Stufft don...@stufft.io 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
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
13 matches
Mail list logo
