I heard back from Enthought on this part of the proposal. They could
accommodate this change.
1) The layout for the python root directory for all platforms should be
as follows:
stdlib = {base/userbase}/lib/
platstdlib = {base/userbase}/lib/
purelib = {base/userbase}/lib/site-packages
platlib
On 03/23/2012 09:22 PM, PJ Eby wrote:
On Mar 23, 2012 3:53 PM, Carl Meyer c...@oddbird.net
On 03/23/2012 12:35 PM, PJ Eby wrote:
AFAICT, virtualenvs are overkill for most development anyway. If you're
not using distutils except to install dependencies, then configure
distutils to install
On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer c...@oddbird.net wrote:
No disagreement here. I think virtualenv's sweet spot is as a convenient
tool for development environments (used in virtualenvwrapper fashion,
where the file structure of the virtualenv itself is hidden away and you
never
On 3/26/2012 12:27 PM, PJ Eby wrote:
On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer c...@oddbird.net
mailto:c...@oddbird.net wrote:
No disagreement here. I think virtualenv's sweet spot is as a
convenient
tool for development environments (used in virtualenvwrapper fashion,
where
On 3/26/2012 1:21 PM, Glenn Linderman wrote:
Hmm. And here's something else that might be missing: integration of
the launcher with .py files that are actually ZIP archives... where
does it find the #! line? (probably it can't, currently -- I couldn't
figure out how to make it do it). Is it
On Sat, Mar 24, 2012 at 4:35 AM, PJ Eby p...@telecommunity.com wrote:
Just dumping things in a directory adjacent to the corresponding scripts is
the original virtualenv, and it still works just dandy -- most people just
don't *know* this. (And again, if there are tools out there that *don't*
On Sat, Mar 24, 2012 at 07:19, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Mar 24, 2012 at 4:35 AM, PJ Eby p...@telecommunity.com wrote:
Just dumping things in a directory adjacent to the corresponding scripts is
the original virtualenv, and it still works just dandy -- most people just
By dodging the issue entirely - anything I might want to regularly run from
a source checkout I execute with -m. It gets sys.path right automatically
and I don't need to care about platform specific executable naming
conventions.
--
Sent from my phone, thus the relative brevity :)
On 23 March 2012 03:20, Brian Curtin br...@python.org wrote:
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
all expressed that they have existing tools that would break and would need
to be adjusted to match the new location of the python.exe, because that
location
VanL wrote:
As this has been brought up a couple times in this subthread, I figured that
I would lay out the
rationale here.
There are two proposals on the table: 1) Regularize the install layout, and
2) move the python
binary to the binaries directory. This email will deal with the
On 23/03/2012 7:10 PM, Paul Moore wrote:
On 23 March 2012 03:20, Brian Curtinbr...@python.org wrote:
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
all expressed that they have existing tools that would break and would need
to be adjusted to match the new location of
On 22 March 2012 23:15, VanL van.lindb...@gmail.com wrote:
Another use case was just pointed out to me: making things consistent with
buildout. Given a similar use
case (create repeatable cross platform environments), they create and use a
'bin' directory for executable files.
Another
On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:
Even if you are using tools that don't use distutils' configuration settings
for these directories, why not simply fix those tools so that they do?
Thats what I do currently - I set things to bin and patch Python and the tools
so that
On Friday, March 23, 2012 at 1:35 PM, PJ Eby wrote:
Tool developers are going meh about your proposal because it doesn't
actually solve any problems for them: they still have to support the old
layout, and if their code already uses distutils' facilities for obtaining
paths, there's
On Mar 23, 2012 4:19 PM, VanL van.lindb...@gmail.com wrote:
Three notes. FIrst, distutils.cfg doesn't always work because it is
centered around the idea of set paths that are the same each time - which
doesn't always work with virtualenvs.
And the virtualenv doesn't contain its own copy of
On Mar 23, 2012 3:53 PM, Carl Meyer c...@oddbird.net wrote:
Hi PJ,
On 03/23/2012 12:35 PM, PJ Eby wrote:
AFAICT, virtualenvs are overkill for most development anyway. If you're
not using distutils except to install dependencies, then configure
distutils to install scripts and libraries
On Mar 23, 2012 10:21 PM, PJ Eby p...@telecommunity.com wrote:
On Mar 23, 2012 4:19 PM, VanL van.lindb...@gmail.com wrote:
Three notes. FIrst, distutils.cfg doesn't always work because it is
centered around the idea of set paths that are the same each time - which
doesn't always work with
On 21/03/2012 23:03, Paul Moore wrote:
On 21 March 2012 22:43, Mark Hammondskippy.hamm...@gmail.com wrote:
On 22/03/2012 1:22 AM, Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
Eric is correct - tools will be broken by this change. However, people seem
willing
As this has been brought up a couple times in this subthread, I figured
that I would lay out the rationale here.
There are two proposals on the table: 1) Regularize the install layout,
and 2) move the python binary to the binaries directory. This email will
deal with the first, and a second
[PART 2: Moving the python binary]
There are two proposals on the table: 1) Regularize the install layout,
and 2) move the python binary to the binaries directory. This email
deals with the second issue exclusively. This has been the more
contentious issue.
2) Moving the Python exe:
A
On 22 March 2012 14:17, VanL van.lindb...@gmail.com wrote:
As this has been brought up a couple times in this subthread, I figured that
I would lay out the rationale here.
I'm repeating myself here after I promised not to. My apologies, but I
don't think this posting captures the debate
Hi Paul,
To start with, I appreciate your comments, and it is worth having both
sides expressed.
On 3/22/2012 12:59 PM, Paul Moore wrote:
I'm repeating myself here after I promised not to. My apologies, but I
don't think this posting captures the debate completely. One reason I
suggested a
Another use case was just pointed out to me: making things consistent with
buildout. Given a similar use case (create repeatable cross platform
environments), they create and use a 'bin' directory for executable files.
___
Python-Dev mailing list
(resending, only sent to Van the first time)
FWIW, I avoid the directory naming problems Van describes entirely by
including my scripts in the source package and running them with the -m
switch.
So python -m pulpdist.manage_site, for example, is PulpDist's Django
administration client wrapper. I
Given the cost of the change, and the advent of the PEP-397 Launcher, I
also vote -1.
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Thu, Mar 22, 2012 at 12:59, Paul Moore p.f.mo...@gmail.com wrote:
Note - that is not Regularizing the layout. You have not made any
changes to OS/2 (which matches Windows at the moment).
I think that would be a wasted effort with OS/2 entering unsupported
mode in 3.3, and OS/2 specific code
On Thu, Mar 22, 2012 at 13:57, VanL van.lindb...@gmail.com wrote:
Honestly, I didn't expect that much resistance. None of the people I talked
to in person even cared, or if they did, they thought that consistency was a
benefit. But now that virtualenvs are going in in 3.3, I see this as the
2012/3/22 VanL van.lindb...@gmail.com:
Open Issues:
If we do put python.exe on PATH (whether it's in bin or not), we have
to debate how to handle people having multiple versions of python on
their machine. In a post-PEP 397 world, no Python is the machine
default - .py files are associated
On Thu, Mar 22, 2012 at 18:26, Ethan Furman et...@stoneleaf.us wrote:
Given the cost of the change, and the advent of the PEP-397 Launcher, I also
vote -1.
Can you provide some justification other than a number? It's a pretty
cheap change and the launcher solves somewhat of a different problem.
[snipped some CCs]
On 23/03/2012 2:20 PM, Brian Curtin wrote:
...
I get that tools could be affected. I had two IDE makers at PyCon
immediately throw up red flags to this change. I think one of them was
about to charge the stage during my talk. When it was mentioned that
we could point them to
Mark, MAL, Martin, Tarek,
Could you comment on this?
This is in the context of changing the name of the 'Scripts' directory
on windows to 'bin'. Éric brings up the point (explained more below)
that if we make this change, packages made/installed the new packaging
infrastructure and those
Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
This is in the context of changing the name of the 'Scripts' directory
on windows to 'bin'. Éric brings up the point (explained more below)
that if we make this change, packages made/installed the new packaging
On 22/03/2012 1:22 AM, Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
Eric is correct - tools will be broken by this change. However, people
seem willing to push forward on this and accept such breakage as the
necessary cost.
MAL, in his followup, asks what the
On 21 March 2012 22:43, Mark Hammond skippy.hamm...@gmail.com wrote:
On 22/03/2012 1:22 AM, Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
Eric is correct - tools will be broken by this change. However, people seem
willing to push forward on this and accept
Cleaning up the absurd CC line
On Thu, Mar 22, 2012 at 8:03 AM, Paul Moore p.f.mo...@gmail.com wrote:
I agree on all points here. I don't understand quite why backward
compatibility is being treated so lightly here. But equally, I've made
my points and have little further to add.
As a
For those who missed it, in http://bugs.python.org/issue14302, Martin
recently commented:
After more discussion, it appears that this change is too incompatible
to be done in a single release.
Therefore, I propose a long-term change into this direction, with the
actual change not happening
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of the latest
discussion.
A question for you Mark, Paul,
On 20/03/2012 14:08, VanL wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of the latest
discussion.
Germane to this discussion, I reached out for feedback. Most people
didn't care about the issue, or were slightly inclined to have it be
uniform across platforms.
As Terry mentioned, I think that long-term uniformity will benefit
everybody down the line, and that is the way to go.
The most
In hearing from a couple people who teach python to beginners, this is a
substantial hurdle - the first thing they need to do is to edit their
environment to add these directories to the PATH.
This is something I never understood. On Windows, it's custom to launch
programs from the start menu,
On 3/20/2012 10:52 AM, Martin v. Löwis wrote:
In hearing from a couple people who teach python to beginners, this is a
substantial hurdle - the first thing they need to do is to edit their
environment to add these directories to the PATH.
This is something I never understood. On Windows, it's
On Tue, Mar 20, 2012 at 10:52, Martin v. Löwis mar...@v.loewis.de wrote:
In hearing from a couple people who teach python to beginners, this is a
substantial hurdle - the first thing they need to do is to edit their
environment to add these directories to the PATH.
This is something I never
1. Run python from the start menu.
- Import sys, fiddle with sys.path to add my module, import/run my
module, do my tests. When you exit /hard error out, the python window
disappears.
2. Double-click the .py file
- Runs the file, but then disappears immediately (unless you put in
On 3/20/2012 11:19 AM, Martin v. Löwis wrote:
No - there is an version #3a: 3.a) Get a shell and run the script CD
into the directory, then directly run foo.py, without prefixing it
with python.exe. This doesn't require any changes to the path, and is
shorter in usage than having the path
On 3/20/2012 12:02 PM, VanL wrote:
On 3/20/2012 10:52 AM, Martin v. Löwis wrote:
In hearing from a couple people who teach python to beginners, this is a
substantial hurdle - the first thing they need to do is to edit their
environment to add these directories to the PATH.
This is something I
On 20 March 2012 14:08, Lindberg, Van van.lindb...@haynesboone.com wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not
When IDLE crashes, running it from a cmd window is the only way to
get a traceback to help diagnose the problem.
Certainly. In this case, there is no PATH issue, though: you have to CD
into the Python installation, anyway, to start IDLE - and there you have
python.exe in the current directory.
On 03/20/2012 12:19 PM, Paul Moore wrote:
I also note that I'm assuming virtualenv will change to match whatever
the Python version it's referencing does. I don't see how you can
guarantee that, but if there are discrepancies between virtualenvs and
installed Pythons, my level of objection
On 13 March 2012 20:43, VanL van.lindb...@gmail.com wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
As this is being considered an 'incompatible
On 20 March 2012 14:27, VanL van.lindb...@gmail.com wrote:
Germane to this discussion, I reached out for feedback. Most people didn't
care about the issue, or were slightly inclined to have it be uniform across
platforms.
As Terry mentioned, I think that long-term uniformity will benefit
On 3/20/2012 1:50 PM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanLvan.lindb...@gmail.com wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
On 3/20/2012 1:56 PM, Paul Moore wrote:
This is covered (better, IMO) by PEP 397 - Python Launcher for
Windows. Step 2, just run py. If you prefer a particular version,
run py -2 or py -3 or py -3.2.
Interesting. I haven't played around with that at all, so can't comment.
I will have to
On 3/20/2012 1:19 PM, Paul Moore wrote:
Somewhat. I don't really object to #1, but mildly object to #2. I also
note that the proposals round the Lib directory seem to have
disappeared. I assume those have been dropped - they were the ones I
did object to.
They are of secondary importance to
On 20 March 2012 19:35, Lindberg, Van van.lindb...@haynesboone.com wrote:
I would like to know if you would object to user lib installs matching
the system install. I.e., would it cause problems with you if it were
just 'lib' everywhere, with no 'lib/python{version}'? It sounded like
adding
On 20 March 2012 19:22, VanL van.lindb...@gmail.com wrote:
There are a number of casual users that probably only have one version
installed, but every python user/dev on windows that I know has one python
that they consider to be python, and everything else needs to be launched
with a suffix
On 3/20/2012 3:15 PM, Paul Moore wrote:
On 20 March 2012 19:35, Lindberg, Vanvan.lindb...@haynesboone.com wrote:
I would like to know if you would object to user lib installs matching
the system install. I.e., would it cause problems with you if it were
just 'lib' everywhere, with no
On 3/20/2012 11:50 AM, Merlijn van Deen wrote:
As this is being considered an 'incompatible change' on the bug
tracker item [1] in any case, I'd like to mention that this might also
be a convenient moment to re-think the default install location. After
all, software is supposed to be installed
On 3/20/2012 3:31 PM, Paul Moore wrote:
Serious question: Given a brand new PC, if you were installing Python
2.7, 3.2, 3.3a1, jython, and pypy, what would you do (beyond simply
running 5 installers) to get your environment set up the way you want?
I install each python in its own directory:
On 21/03/2012 1:08 AM, Lindberg, Van wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of the latest
On 3/20/2012 4:49 PM, Mark Hammond wrote:
So I'm assuming that:
* The executable (and DLL) are moved to a bin directory in an
installed Python.
* distutils etc will change to install all scripts (or executables
generated from scripts) into that same directory. IOW, Scripts
would die.
* A
On 20 March 2012 22:00, VanL van.lindb...@gmail.com wrote:
On 3/20/2012 4:49 PM, Mark Hammond wrote:
So I'm assuming that:
* The executable (and DLL) are moved to a bin directory in an installed
Python.
* distutils etc will change to install all scripts (or executables
generated from
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanLvan.lindb...@gmail.com wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work
On 21/03/2012 9:45 AM, R. David Murray wrote:
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammondskippy.hamm...@gmail.com
wrote:
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in
On 3/20/2012 4:25 PM, Mark Hammond wrote:
I think it does. Consider I've installed Python as a system
install. Now I want to install some other package - ideally that
installer will request elevation - all well and good - the .py files
are installed. However, next time I want to run Python,
On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote:
It's worth remembering Éric's point - distutils is frozen and changes
are in theory not allowed. This part of the proposal is not possible
without an exception to that ruling. Personally, I don't see how
making this change could be a
Hi,
Le 20/03/2012 21:40, VanL a écrit :
On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote:
It's worth remembering Éric's point - distutils is frozen and changes
are in theory not allowed. This part of the proposal is not possible
without an exception to that ruling. Personally, I don't
R. David Murray wrote:
My understanding, though, is that Python
does make a distinction between a system install of Python and
a per-user one, so I don't think your objection really applies.
Seems to me that for Python at least, the important distinction
is not so much where the files are
On 17 March 2012 05:28, Mark Hammond skippy.hamm...@gmail.com wrote:
I hate to seem like I'm piling on now after panning your last brainstorm
:-), but... this would be quite problematic for virtualenv users, many
of whom do rely on the fact that the virtualenv stuff is confined to
within a
17.03.12 13:57, Paul Moore написав(ла):
As there is no
way of knowing the Python version without running Python, this is too
slow to be practical.
Cold start:
$ time python3 --version
Python 3.1.2
real0m0.073s
user0m0.004s
sys 0m0.004s
Hot start:
$ time python3 --version
Python
On 17 March 2012 14:07, Serhiy Storchaka storch...@gmail.com wrote:
17.03.12 13:57, Paul Moore написав(ла):
As there is no
way of knowing the Python version without running Python, this is too
slow to be practical.
Cold start:
$ time python3 --version
Python 3.1.2
real 0m0.073s
On 3/17/2012 10:50 AM, Paul Moore wrote:
Meh. None of this is a real issue. It's just some extra messy coding.
But Van's point is that this proposal gives him less hard coding.
Beyond pointing out that it gives me more, I don't have much to add.
I suspect a case could be made that
On 16 March 2012 00:12, Carl Meyer c...@oddbird.net wrote:
Changing the directory name is in fact a new and different (and much
more invasive) special case, because distutils et al install scripts
there, and that directory name is part of the distutils install scheme.
Installers don't care
On 3/15/2012 6:19 PM, Mark Hammond wrote:
[At least I think that is your proposal - can you confirm that the
directory layouts in your proposal exactly match the directory
layouts in virtual envs on all other platforms? ie, that
inconsistencies like the python{py_version_short} suffix will not
Carl -
Changing the directory name is in fact a new and different (and much
more invasive) special case, because distutils et al install scripts
there, and that directory name is part of the distutils install scheme.
Installers don't care where the Python binary is located, so moving it
in
On 3/16/2012 3:38 AM, Paul Moore wrote:
On 16 March 2012 00:12, Carl Meyerc...@oddbird.net wrote:
Changing the directory name is in fact a new and different (and much
more invasive) special case, because distutils et al install scripts
there, and that directory name is part of the distutils
Hi,
Le 16/03/2012 16:17, Lindberg, Van a écrit :
On 3/16/2012 3:38 AM, Paul Moore wrote:
1. The incompatibilities between platforms is precisely the problem
that sysconfig is designed to solve, isn't it? So tools in Python will
either use sysconfig (and be correct regardless of layout) or
On 16 March 2012 15:17, Lindberg, Van van.lindb...@haynesboone.com wrote:
This is not a we should be consistent argument - I know that would
never fly. I do cross-platform dev all the time (develop on Windows and
Mac, deploy on Linux) and so this bites me *every single time* I want to
get a
On 3/16/2012 10:53 AM, Paul Moore wrote:
The only way I can read this to make sense is that you somehow
consider the Python installation as part of your development
environment (you mentioned source control earlier in the thread -
surely you don't manage your Python installation in source
On 3/16/2012 9:22 AM, Lindberg, Van wrote:
On 3/16/2012 10:53 AM, Paul Moore wrote:
The only way I can read this to make sense is that you somehow
consider the Python installation as part of your development
environment (you mentioned source control earlier in the thread -
surely you
On 3/16/2012 11:57 AM, Glenn Linderman wrote:
So I think I'm finally beginning to see the underlying reason why Van is
desiring this consistency: It is not that he wants to check in his
installation of Python, but that he wants to check in his installation
of his packages and scripts into a
On 3/16/2012 12:22 PM, Lindberg, Van wrote:
env/
bin/
python
pip
easy_install
my_script
In http://bugs.python.org/issue14302 Brian Curtin claims
After talks at PyCon with several people, python.exe will live in
C:\Python33\bin rather than C:\Python33 to come more
Hi Van,
On 03/16/2012 08:08 AM, Lindberg, Van wrote:
Changing the directory name is in fact a new and different (and much
more invasive) special case, because distutils et al install scripts
there, and that directory name is part of the distutils install scheme.
Installers don't care where
On 17/03/2012 7:22 AM, Carl Meyer wrote:
...
I don't want to make the internal layout of a virtualenv differ from the
system Python layout on the same platform, which (IIUC) was Mark's proposal.
Just to be clear, I made that suggestion in an effort to keep both
myself and Van - that the
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
...
For the sake of brain-storming, how about this:
* All
On Fri, Mar 16, 2012 at 19:53, Mark Hammond skippy.hamm...@gmail.com wrote:
For the sake of brain-storming, how about this:
* All executables and scripts go into the root of the Python install. This
directory is largely empty now - it is mainly a container for other
directories. This would
On 17/03/2012 12:07 PM, Brian Curtin wrote:
On Fri, Mar 16, 2012 at 19:53, Mark Hammondskippy.hamm...@gmail.com wrote:
For the sake of brain-storming, how about this:
* All executables and scripts go into the root of the Python install. This
directory is largely empty now - it is mainly a
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2 directories on
the PATH and mean existing
On 3/16/2012 6:25 PM, Carl Meyer wrote:
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2
On 17/03/2012 12:25 PM, Carl Meyer wrote:
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
The fact is that most code doesn't know about this, only installers or
virtual
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so sure. My concern is that this *will* break
On 03/15/2012 04:19 PM, Mark Hammond wrote:
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so
On 16/03/2012 10:48 AM, Carl Meyer wrote:
...
The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same platform, to avoid any need to special-case
On 03/15/2012 05:10 PM, Mark Hammond wrote:
On 16/03/2012 10:48 AM, Carl Meyer wrote:
The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all
In
view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html
van.lindberg at gmail.com posted:
1) The layout for the python root directory for all platforms should be
as follows:
stdlib = {base/userbase}/lib/python{py_version_short}
platstdlib =
On 3/13/2012 9:58 PM, Terry Reedy wrote:
Given that we already repeat it, isn't it better to be consistent?
But there is no repetition currently on Windows installations.
I though you were just proposing to switch lib (lower-cased, and scripts
renamed as bin, and pythonxx). So I do not think
On 3/13/2012 9:57 PM, VanL wrote:
On Mar 13, 2012, at 8:37 PM, Martin v. Löwis mar...@v.loewis.de wrote:
The installation will end up in
c:\python33\lib\python3.3
which has the software name and version twice in the path.
Do we *really* need this?
We *already* have this. The only
On 3/14/2012 9:53 AM, Jim J. Jewett wrote:
In
view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html
van.lindberg at gmail.com posted:
1) The layout for the python root directory for all platforms should be
as follows:
stdlib =
On 3/14/2012 10:09 AM, Scott Dial wrote:
I think you are confusing two different configuration sections in
sysconfig.cfg:
[nt]
stdlib = {base}/Lib
platstdlib = {base}/Lib
purelib = {base}/Lib/site-packages
platlib = {base}/Lib/site-packages
include = {base}/Include
platinclude = {base}/Include
1 - 100 of 115 matches
Mail list logo
