Re: [Distutils] desirability of multiple, divergent Python instances

[Daniel Krech]

On Apr 14, 2008, at 12:59 AM, Stephen Waterbury wrote:
> Ben Finney wrote:
>> Greg Ewing <[EMAIL PROTECTED]> writes:
>>
>>> Gael Varoquaux wrote:
 a second Python needs to be installed on top of the system Python
 to add modules to it.
>>> Maybe the system should come with two pythons installed, one for use
>>> by the system and the other for users to add things to. Or at least
>>> be set up so that it appears that way -- they might share files
>>> under the hood.
>>
>> I can't see how this is a good idea. I've seen it mentioned multiple
>> times in this thread, but without justification.
>>
>> It's my position that the Python instance one uses for development
>> should diverge as little as possible from the default system  
>> instance.
>> Otherwise one is actively pursuing a recipe for dependency failures
>> when one eventually deploys the result.
>
>> Yes, there should be a way to deploy the code one is actively
>> developing and testing to some location that will not affect the rest
>> of the operation of the system. That is a far cry from asking that
>> there should be multiple, divergent Python instances on the system.
>>
>> The further step of saying that the operating system should not use
>> the same Python instance as a "user" on the system (and note that the
>> line between those is far from clear), but instead should use some
>> Python instance that behaves differently from every other use of
>> Python on the system, seems like an even worse proposition, for the
>> above reasons.
>>
>> Help me understand, please.
>
> Have you read my proposal?  It's in the message posted by me to this
> thread at 12:31 PM today.
>
> My main motivation in proposing it is to give the user complete  
> control
> over the Python environment that is in their path -- which is not  
> easy to
> do on Debian/Ubuntu at the moment -- by giving the Python utilities  
> and
> packages that OS-related functions depend on a completely insular  
> Python
> environment that the OS can manage however it sees fit.  In my view,  
> both
> as a developer and a user, but especially as a developer, it would  
> make
> life easier.

This seems related to the use case I was going after in 'autoinstall'.  
Which is to move the control of the Python environment to the  
application. This way each application can have its own insular Python  
environment.

A first baby step in that direction:

 http://pypi.python.org/pypi/autoinstall/0.1a2

Currently it only supports binding dotted packages names to URLs  
(relative or absolute) that point to zip importable versions of the  
package. But I've been using it some and it's been making my life  
easier indeed.

Curious what people think of a per application approach? The use case  
seems to be mentioned a fair bit in the various threads.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] desirability of multiple, divergent Python instances

[Stephen Waterbury]

Stephen Waterbury wrote:
> Have you read my proposal?  It's in the message posted by me to this
> thread at 12:31 PM today.

That's not a good way to reference it, of course, so here it is:

Definitions:

"system Python" -- the Python (and its site-pkgs, etc.) that any Python
scripts used by the OS depend on, which would of course by solely determined
by the OS.

This would be distinct, in my proposal, from any packages named
"python" or "python.x" in the package namespace of the system package
manager (e.g. apt).

What I am proposing:

1)  that the OS comes with its own "system Python", which is installed
not as the "python" package, but as some OS-required package
(maybe call it "system-python" or something) and it goes into
/usr/system/bin/python or whatever -- it doesn't matter what the
path is as long as it's not /usr/bin or anything on the default
path.  And system utilities that are python scripts should have
their own system-specific, hard-coded shebang line.

2)  that separately from the "system Python", the available packages
managed by the system's package manager include one or more "python.x"
packages which are python interpreters that the user or sysadmin can
optionally install, and which go into /usr, and which would share
*nothing* with the "system Python".  And the system package
manager -- e.g., apt on Debian/Ubuntu systems) would have all its usual
nicely-packaged python apps (python-this, python-that, ...) that would
also install into /usr and use the nicely-packaged python (not to be
confused with the "system Python" of 1).

Fire away!  :)

Steve
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] desirability of multiple, divergent Python instances

[Stephen Waterbury]

Ben Finney wrote:
> Greg Ewing <[EMAIL PROTECTED]> writes:
> 
>> Gael Varoquaux wrote:
>>> a second Python needs to be installed on top of the system Python
>>> to add modules to it.
>> Maybe the system should come with two pythons installed, one for use
>> by the system and the other for users to add things to. Or at least
>> be set up so that it appears that way -- they might share files
>> under the hood.
> 
> I can't see how this is a good idea. I've seen it mentioned multiple
> times in this thread, but without justification.
> 
> It's my position that the Python instance one uses for development
> should diverge as little as possible from the default system instance.
> Otherwise one is actively pursuing a recipe for dependency failures
> when one eventually deploys the result.

> Yes, there should be a way to deploy the code one is actively
> developing and testing to some location that will not affect the rest
> of the operation of the system. That is a far cry from asking that
> there should be multiple, divergent Python instances on the system.
> 
> The further step of saying that the operating system should not use
> the same Python instance as a "user" on the system (and note that the
> line between those is far from clear), but instead should use some
> Python instance that behaves differently from every other use of
> Python on the system, seems like an even worse proposition, for the
> above reasons.
> 
> Help me understand, please.

Have you read my proposal?  It's in the message posted by me to this
thread at 12:31 PM today.

My main motivation in proposing it is to give the user complete control
over the Python environment that is in their path -- which is not easy to
do on Debian/Ubuntu at the moment -- by giving the Python utilities and
packages that OS-related functions depend on a completely insular Python
environment that the OS can manage however it sees fit.  In my view, both
as a developer and a user, but especially as a developer, it would make
life easier.

Steve

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] desirability of multiple, divergent Python instances (was: shebang line modified by setuptools)

[Ben Finney]

Greg Ewing <[EMAIL PROTECTED]> writes:

> Gael Varoquaux wrote:
> > a second Python needs to be installed on top of the system Python
> > to add modules to it.
> 
> Maybe the system should come with two pythons installed, one for use
> by the system and the other for users to add things to. Or at least
> be set up so that it appears that way -- they might share files
> under the hood.

I can't see how this is a good idea. I've seen it mentioned multiple
times in this thread, but without justification.

It's my position that the Python instance one uses for development
should diverge as little as possible from the default system instance.
Otherwise one is actively pursuing a recipe for dependency failures
when one eventually deploys the result.

Yes, there should be a way to deploy the code one is actively
developing and testing to some location that will not affect the rest
of the operation of the system. That is a far cry from asking that
there should be multiple, divergent Python instances on the system.

The further step of saying that the operating system should not use
the same Python instance as a "user" on the system (and note that the
line between those is far from clear), but instead should use some
Python instance that behaves differently from every other use of
Python on the system, seems like an even worse proposition, for the
above reasons.

Help me understand, please.

-- 
 \"Most people don't realize that large pieces of coral, which |
  `\   have been painted brown and attached to the skull by common |
_o__) wood screws, can make a child look like a deer."  -- Jack Handey |
Ben Finney

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

[Greg Ewing]

David Cournapeau wrote:
> There are two ways of looking at it, I think. One is to think that linux 
> FHS (and unix in general) is totally broken.

I don't think it's *totally* broken. I do think it goes
overboard with splitting things up and scattering them
around. I understand that there are reasons for some of
that, but I don't see why e.g. includes, library files
and other resources used by a package can't be kept
together.

> I personally really like 
> how gobo linux tries to go around that:
> 
> http://www.gobolinux.org/

Hadn't heard of that before -- it sounds quite nice!
Rather like MacOSX might look if it had dependency
management.

-- 
Greg
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

[Greg Ewing]

John J Lee wrote:
> If you have a network connection, about the only reason for not wanting 
> an app to be "installed" is that it has changed the behaviour of your 
> system somehow, just by being in the "installed" state.

If you have a continuous high-speed network connection and
aren't concerned about cost or bandwidth use or disk space
taken up, it might make sense to have apps downloaded on demand,
cached, etc. But not everyone works that way. I don't, much of
the time. I prefer it when downloading an app and putting it
on my system is an explicit step.

I know you can use 0install that way, but I do it already on
my MacOSX system without needing any special tool. :-)

>> Yes, ROX is very MacOSX-like, but I don't think it has
>> anything to do with 0install.
> 
> 0install provides one way of implementing that kind of system.

But it doesn't, if by "that kind of system" you mean one where
an app or library is just an ordinary filesystem object. A
0install app appears to be very far from ordinary.

> If you 
> want to share data, it's a better way than unshared directories of 
> files.

There's nothing to stop a MacOSX user from putting an app in
a publically-readable place and letting other people use it.
I don't see what the big deal is there.

>> If ROX apps included a checksum, and the system verified it
>> before running the app, that would give you the same thing
>> trust-wise, I think.
> 
> That's an interesting idea, but how would the system find the app?

The system doesn't have to find the app -- the user finds the
app, using the same techniques he uses to find anything else in
the filesystem he's interested in.

-- 
Greg
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Stephen Waterbury]

Greg Ewing wrote:
> Gael Varoquaux wrote:
>> a second Python
>> needs to be installed on top of the system Python to add modules to it.
> 
> Maybe the system should come with two pythons installed,
> one for use by the system and the other for users to add
> things to. Or at least be set up so that it appears that
> way -- they might share files under the hood.

That was exactly my proposal -- see my message in this thread
at 12:31 PM today.

Steve




___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Greg Ewing]

Gael Varoquaux wrote:
> a second Python
> needs to be installed on top of the system Python to add modules to it.

Maybe the system should come with two pythons installed,
one for use by the system and the other for users to add
things to. Or at least be set up so that it appears that
way -- they might share files under the hood.

-- 
Greg
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

[David Cournapeau]

Greg Ewing wrote:
>
> That looks interesting, but I'm not sure I'd quite
> call it "something like". It looks like another case
> of adding more complexity to fight existing complexity,
> rather than removing the original complexity.
>

You won't be able to remove the initial complexity, because it is a 
feature. Honestly, one of the thing which annoys me the most when I have 
to use mac os X or windows is the lack of package management.

Now, I don't think the situation on linux is ideal either. There are 
some technical issues, and some social issues; the worst thing to do is 
to find a technical solution to a social problem, so it is important to 
separate the two kinds, I think. On windows, most windows developers, as 
I understand it, do not have a strong need for package manager because 
they have almost everything they want with visual studio and MS dev 
tools. On a new linux machine, I may do apt-get install devtools. On 
windows, I run setup.exe for VS, plus the full Windows SDK. In a way, 
they do the same thing: providing everything a developer may need with 
as little hassle as possible for the developer (compilers, api, sdk, 
docs, etc... in a way which such as all the disparate things work together).

> In other words, it seems to be just another package
> manager, albeit a particulary nice-sounding one.

There are two ways of looking at it, I think. One is to think that linux 
FHS (and unix in general) is totally broken. I personally really like 
how gobo linux tries to go around that:

http://www.gobolinux.org/

It is like stow on steroids: I try to avoid installing anything from 
sources which is not handled through stow, and gobolinux just go one 
step further (quite a big step).

The other one is to say disk space is cheap, just bundle everything (ala 
mac os X). 0install is a partial solution. There are also projects like 
klik or glick (done by a Red Had employer), which may be more similar to 
what you are after:

Note that mac os X is a combination of the two in some ways.

cheers,

David
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

[David Cournapeau]

Gael Varoquaux wrote:
>
> 90 % (at least) of the world does not have such database. I, and probably
> you, have such a very nice database. I works well, and we can choose to
> forget the problems our users are facing. It does not solve them though.
>
> In addition, packaging is system-specific. I recently had to learn some
> Debian packaging, because I wanted my Ubuntu and Debian users to be able
> to use my projects seamlessly. What about RPMs for RHEL, Fedora,
> Mandriva? ... and coronary packages? and MSIs? ... When do I find time to
> do development if I have to learn all this packaging.

There is no way around it: you have to learn about them. It is a PITA, 
but there is a limit of what a tool can do, specially for things like 
installers. I agree it would be fantastic to have an abstraction on all 
those packaging systems, but I don't think it is possible without a huge 
amount of work if at all. Deploying softwares is simply a very big 
problem that won't go away magically, even if eggs were perfect and 
nobody would complain about it. I strongly believe it is one of the 
reason why windows has been so popular: instead of targetting many 
combinations, you target windows, which does everything you ever need to 
do, and MS kind of guarantee that something which works today will still 
work in ten years.

The only reliable way to handle dependencies if you don't have huge 
ressources is to bundle everything; IOW, not handling them. That's how 
most softwares work anyway on mac os X and windows: matlab for example 
is a huge thing with hundred of MB; most softwares do not depend on 
something else except the OS, which is a much more known thing on mac os 
X and windows than on linux. If you want to update a small part of it, 
life is tough, you upgrade everything. Of course, part of the thing is 
that it brings more revenue to mathworks, but I don't think it is the 
only reason. I also know some open source projects which do the same 
because they simply cannot track api changes (ardour, for example: if 
you build ardour from sources, you will get a private copy of the whole 
gtk stack).

cheers,

David
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Phillip J. Eby]

At 11:24 PM 4/13/2008 +0200, Gael Varoquaux wrote:
>Here is how things are happening (I simplified a bit the example, because
>I have a lot of things in my sys.path):
>
>[EMAIL PROTECTED]:~$ python -c "import sys; print sys.path"
>['', '/usr/local/lib/python2.5/site-packages/configobj-4.4.0-py2.5.egg',
>'/usr/lib/python2.5/site-packages', '/usr/lib/python25.zip',
>'/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
>'/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload',
>'/usr/local/lib/python2.5/site-packages',
>'/usr/lib/python2.5/site-packages',
>'/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode']
>[EMAIL PROTECTED]:~$ export PYTHONPATH="/home/varoquau/python:"
>[EMAIL PROTECTED]:~$ python -c "import sys; print sys.path"
>['', '/usr/local/lib/python2.5/site-packages/configobj-4.4.0-py2.5.egg',
>'/usr/lib/python2.5/site-packages', '/home/varoquau/python',
>'/home/varoquau', '/usr/lib/python25.zip', '/usr/lib/python2.5',
>'/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk',
>'/usr/lib/python2.5/lib-dynload',
>'/usr/local/lib/python2.5/site-packages',
>'/usr/lib/python2.5/site-packages',
>'/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode']
>
>Notice how what I added in my PYTHONPATH (the environment variable) is
>behind the egg. Well, what if I wanted to override configobj by my own
>version, in "/home/varoquau/python"? I am not able to do this without
>writing some Python code to monkey patch sys.path. The "$PYTHONPATH"
>should always come in front of everything. Are my explanations clear this
>time?
>
>Maybe this was not a feature, and another bug.

It's the same bug, actually.  Ideally, the configobj.egg should be in 
front of the /usr/lib/python25.zip, but not any further forward than 
that.  The last line of easy-install.pth is essentially too crude in 
its insertion method: it defaults to inserting at position zero, when 
it should default to a location that is either directly before the 
directory containing the .pth, or if that directory is the primary 
site-packages directory, then it should insert in a position that is 
after PYTHONPATH and the script directory, but before the stdlib.

Now, if someone will contribute an alternative postamble for 
easy-install.pth that can figure all that out in a 
cross-platform/cross-python-version way -- and within the constraints 
of the limited code you can jam into a .pth file -- we can get it fixed.  :)

(The cross-python-version comment is a reference to the fact that the 
'site' module was heavily rewritten in either 2.4 or 2.5; I forget 
which.  So the tools available from inside a .pth file vary somewhat 
between Python versions.)

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Gael Varoquaux]

On Sun, Apr 13, 2008 at 05:12:48PM -0400, Phillip J. Eby wrote:
> However, now that it's a known bug, it's merely an engineering problem to 
> fix it.  :)

Fantastic! I thought it was a feature, so I was unhappy, but if it's only
a bug, well, I know too well that these things happen, and if nobody
reports them, they don't get fixed.


>> With standard Python, I can override the import mechanism using the
>> PYTHONPATH. This way I can make sure that the modules I want get
>> imported. And pretty much all the programs I can think of with a path
>> environment variable behave like this. Now if I have a module installed
>> with setuptools, I no longer have the possibility to do this, because
>> setuptools inserts it self before the PYTHONPATH.
>
> I'm not following you here.  Are you trying to specify the use of a 
> different version of setuptools?  What do you mean by "setuptools inserts 
> itself before the PYTHONPATH"?

Here is how things are happening (I simplified a bit the example, because
I have a lot of things in my sys.path):

[EMAIL PROTECTED]:~$ python -c "import sys; print sys.path"
['', '/usr/local/lib/python2.5/site-packages/configobj-4.4.0-py2.5.egg',
'/usr/lib/python2.5/site-packages', '/usr/lib/python25.zip',
'/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
'/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload',
'/usr/local/lib/python2.5/site-packages',
'/usr/lib/python2.5/site-packages',
'/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode']
[EMAIL PROTECTED]:~$ export PYTHONPATH="/home/varoquau/python:"
[EMAIL PROTECTED]:~$ python -c "import sys; print sys.path"
['', '/usr/local/lib/python2.5/site-packages/configobj-4.4.0-py2.5.egg',
'/usr/lib/python2.5/site-packages', '/home/varoquau/python',
'/home/varoquau', '/usr/lib/python25.zip', '/usr/lib/python2.5',
'/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk',
'/usr/lib/python2.5/lib-dynload',
'/usr/local/lib/python2.5/site-packages',
'/usr/lib/python2.5/site-packages',
'/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode']

Notice how what I added in my PYTHONPATH (the environment variable) is
behind the egg. Well, what if I wanted to override configobj by my own
version, in "/home/varoquau/python"? I am not able to do this without
writing some Python code to monkey patch sys.path. The "$PYTHONPATH"
should always come in front of everything. Are my explanations clear this
time?

Maybe this was not a feature, and another bug. In which case, please
excuse the tone of my previous message. I should have reported the
problem. I thought it was a know one, because it seems so natural to do
the following in a Unix world.

Cheers,

Gaël
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Phillip J. Eby]

At 08:26 PM 4/13/2008 +0200, Gael Varoquaux wrote:
>On Sun, Apr 13, 2008 at 02:04:56PM -0400, Phillip J. Eby wrote:
> > At 05:29 PM 4/13/2008 +0200, Gael Varoquaux wrote:
> >> Of course setuptools will
> >> break this, because it adds itsef to front of the PYTHONPATH, and totally
> >> break the PYTHONPATH semantics (Grrr).
> >
> > The entire point of PYTHONPATH is to be able to put things at the front of
> > it, so I don't see how that's breaking anything.
>
>Well actually, my phrasing in the above was catastrophic. I have mixed
>PYTHONPATH and sys.path. Anyhow, I have a problem with how setuptools
>deals with both:
>
>* sys.path
>
> > When you ask easy_install to install something as the default importable
> > version of that package, the only way to ensure that is by placing that
> > thing at the front of sys.path, to override any other version of it that
> > might be installed elsewhere on sys.path.
>
>What I would want is setuptools to respect the priorities for packages
>depending on where they are installed. In other words, if I install a
>package in /usr/local/lib and this is further down the priorities than
>/usr/lib, then I don't expect this package to override module imports
>happening from /usr/lib.

And you're saying that setuptools does this?  Since when?

[pause to investigate]

Hm...  that's a bug, actually.  If there are multiple 'site' 
directories, then what you describe will indeed happen; eggs in the 
later 'site' directory will indeed override those in the former, 
which should not happen.

The issue is that the postamble of easy-install.pth is simply 
inserting the eggs at the head of sys.path, even in cases where they 
could simply be inserted immediately before the directory the .pth 
file is in.  One minor issue, however, is that eggs in the systemwide 
site-packages must also be able to override the stdlib - so simply 
locating the correct insertion point isn't going to fix the whole problem.

However, now that it's a known bug, it's merely an engineering 
problem to fix it.  :)


>With standard Python, I can override the import mechanism using the
>PYTHONPATH. This way I can make sure that the modules I want get
>imported. And pretty much all the programs I can think of with a path
>environment variable behave like this. Now if I have a module installed
>with setuptools, I no longer have the possibility to do this, because
>setuptools inserts it self before the PYTHONPATH.

I'm not following you here.  Are you trying to specify the use of a 
different version of setuptools?  What do you mean by "setuptools 
inserts itself before the PYTHONPATH"?


>This second problem could probably easily be fixed, though, by some more
>clever monkey patching of the sys.path.

In general, setuptools' path management could be improved by tweaking 
its path hacks so that an egg is positioned only in front of the 
directory that contains it (except for lib/site-packages eggs, which 
need to also override lib).

Patches welcome.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] [issue7] Test 1

[Martin v. Löwis]

New submission from Martin v. Löwis <[EMAIL PROTECTED]>:

Testing the installation

--
messages: 7
nosy: loewis
priority: bug
status: unread
title: Test 1

___
Setuptools tracker <[EMAIL PROTECTED]>

___
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Gael Varoquaux]

On Sun, Apr 13, 2008 at 02:04:56PM -0400, Phillip J. Eby wrote:
> At 05:29 PM 4/13/2008 +0200, Gael Varoquaux wrote:
>> Of course setuptools will
>> break this, because it adds itsef to front of the PYTHONPATH, and totally
>> break the PYTHONPATH semantics (Grrr).
>
> The entire point of PYTHONPATH is to be able to put things at the front of 
> it, so I don't see how that's breaking anything.

Well actually, my phrasing in the above was catastrophic. I have mixed
PYTHONPATH and sys.path. Anyhow, I have a problem with how setuptools
deals with both:

* sys.path

> When you ask easy_install to install something as the default importable 
> version of that package, the only way to ensure that is by placing that 
> thing at the front of sys.path, to override any other version of it that 
> might be installed elsewhere on sys.path.

What I would want is setuptools to respect the priorities for packages
depending on where they are installed. In other words, if I install a
package in /usr/local/lib and this is further down the priorities than
/usr/lib, then I don't expect this package to override module imports
happening from /usr/lib. You can justify what setuptools is doing from
an implementation point of view, but it doesn't change the fact that it
is doing the wrong thing. Wrong because it goes against what Python does.
Thus I have to learn some completely new import semantics to deal with
the fact that some of the packages on my system where installed by
setuptools. In addition there is a good reason behind the standard Python
behavior.

* PYTHONPATH

With standard Python, I can override the import mechanism using the
PYTHONPATH. This way I can make sure that the modules I want get
imported. And pretty much all the programs I can think of with a path
environment variable behave like this. Now if I have a module installed
with setuptools, I no longer have the possibility to do this, because
setuptools inserts it self before the PYTHONPATH. First of all this
really breaks the users expectancies. Second it puts people in a dead
end. Actually it forces them to use setuptools, or to monkey-patch
sys.path themselves, to override the import of a module. Once again you
are expecting your users to know way more than a beginner's knowledge of
Python. Python is simple and does what you expect... no longer. 

This is way worse than not respecting sys.path priorities. I have lost
hours on that, and when I found out why, ... well I won't copy my remarks
about setuptools on this mailing list. And what has happened to me has
probably happened to many.

This second problem could probably easily be fixed, though, by some more
clever monkey patching of the sys.path.

Actually both problems are solvable, if you care about not changing the
way Python works. If you don't care, than make it obvious everywhere. But
even if you do, I think it is a very bad thing, because people will still
fall for the trap (eg I copy my scripts to a new server, which uses
setuptools, although I don't know it, and I actually don't know what
setuptools are). Don't call it Python, if you are going to change
fundamentally the way it works. 

My 2 cents,

Gaël
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Phillip J. Eby]

At 05:29 PM 4/13/2008 +0200, Gael Varoquaux wrote:
>Of course setuptools will
>break this, because it adds itsef to front of the PYTHONPATH, and totally
>break the PYTHONPATH semantics (Grrr).

The entire point of PYTHONPATH is to be able to put things at the 
front of it, so I don't see how that's breaking anything.

When you ask easy_install to install something as the default 
importable version of that package, the only way to ensure that is by 
placing that thing at the front of sys.path, to override any other 
version of it that might be installed elsewhere on sys.path.

Well, the only way short of going through all of sys.path and 
deleting anything that might potentially be in the way.  That 
approach was tried in I think the 0.4 line of setuptools, however, 
and it wasn't very popular.  :)

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

[John J Lee]

On Sun, 13 Apr 2008, Greg Ewing wrote:

> John J Lee wrote:
>
>> It allows you to think about "uninstallation" as "delete the app == delete 
>> the file"
>
> But 0install doesn't do that, as far as I can tell -- it
> still keeps the data in some mysterious form and location
> known only to itself, and requires you to use special tools
> to install/remove apps.

If you have a network connection, about the only reason for not wanting an 
app to be "installed" is that it has changed the behaviour of your system 
somehow, just by being in the "installed" state.  But the presence of an 
app in the 0install cache -- which is what you mean here by "installed" -- 
doesn't change the behaviour of your system.

One other reason, of course, is to free up disk space.  You're correct 
that special tools are needed to manage the cache, and that that 
complicates the UI.  I think that's a fair price to pay for safe sharing 
of data between users.


>> with ROX, it seems very similar to how I imagine Mac OS
>> applications look
>
> Yes, ROX is very MacOSX-like, but I don't think it has
> anything to do with 0install.

0install provides one way of implementing that kind of system.  If you 
want to share data, it's a better way than unshared directories of files. 
That's how 0install and ROX are related, from this perspective.


>> But it also (plausibly) claims to allow sharing of the data that comprises 
>> an application and its dependencies between users who don't trust each 
>> other
>
> If ROX apps included a checksum, and the system verified it
> before running the app, that would give you the same thing
> trust-wise, I think.
[...]

That's an interesting idea, but how would the system find the app?  If it 
doesn't, the data won't be shared.


John

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Floris Bruynooghe]

On Sat, Apr 12, 2008 at 03:26:52PM -0700, Cliff Wells wrote:
> 
> On Sat, 2008-04-12 at 17:53 -0400, Phillip J. Eby wrote:
> > At 12:30 PM 4/12/2008 -0700, Cliff Wells wrote:
> > >PATH is *supposed* to affect applications.
> > 
> > It affects which application you should run, not which interpreter 
> > you run the application with.
> 
> I think that's splitting hairs and pretty much just made up to defend
> your position.

Nope, his statement is very correct.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 13, 2008, at 11:03 AM, Stephen Waterbury wrote:
> Gael Varoquaux wrote:
>> On Sun, Apr 13, 2008 at 07:59:21AM -0400, Barry Warsaw wrote:
>>> On Apr 12, 2008, at 9:41 PM, Stephen Waterbury wrote:
>>
 I used to always set up my own Python[s] in /usr/local
 and put that first in my PATH, but I have gotten lazy lately, and
 sometimes it will bite me. ;)
>>
>>> On Debian and derivatives (e.g. Ubuntu) you might have even more  
>>> fun.
>>> They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of
>>> the system python*!  This means that you can break your system  
>>> Python
>>> by installing a version of Python from source and then distutil'ing
>>> things into there.  Astoundingly, this is promoted as a feature.
>>
>> I want it like that. You are confusing /opt and /usr/local.
>
> Heh ... that shows my Berkeley roots -- I'm not confused,
> I'm just an old SunOS guy still in denial about that damn SysV stuff
> that Solaris brought in, like using /opt instead of /usr/local --
> bah, humbug!  The OS has /usr; /usr/local is *mine* dammit!  ;)

You and me both Steve!  Of course, we're old farts so when we retire  
 the kids can have their /usr/local.  Until then, they'll have  
to pry it out of hands.  :)

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSAI5EXEjvBPtnXfVAQKU3wP+LnbcfTiE9AwDmIdNGrbnijGxWM5xGNgF
Zg42Zs9RWWjjCABoOkZyHw1k3f0mp5DZtgA/XR8joPiVwyq8VV2diIQI4pw/c2No
AGP0XpTOeqjHSm84jEDIT1YaFfp5NTuDzN360zxM4neLi9nG7pVD+OGebL4n/OPh
aSB08rP/vKM=
=cqEh
-END PGP SIGNATURE-
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 13, 2008, at 10:45 AM, Stephen Waterbury wrote:

> Yes, your luck holds -- as does mine, for now ... but since Barry
> works for Canonical (besides being Python's new Release Manager),
> he has a civic responsibility to report Ubuntu Python bugs even if
> his own system works ... and since that can be quite time-consuming,
> I can't blame him for trying to recruit some help ... ;)

I should clarify a few things though: I'm not on the Ubuntu release  
team (I work on Launchpad) and AFAIK Ubuntu simply inherits Debian's  
policy here.  Speaking purely as a user, I think Debian is wrong and  
I've reported bugs on it, and I think they are open to a compromise  
that can work for everyone.  That's as much as I can do (short of  
turning off Python's svn notifications and sneaking a change in -- but  
if I had that power as Python's RM, I'd use it for much more important  
things[1] :).

- -Barry

[1] http://www.artima.com/weblogs/viewpost.jsp?thread=173477

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSAI40nEjvBPtnXfVAQL7BgP9HWIajzqzLq0y4UZmSemHooqoukKnQA9O
sxKAwzXthZPt5P9CUAduZKZqvYSQvSTmtwSMqoBjLGmfJo4WQIQ5BLZrq2s1cO6I
SPPUWQ1RSfHAeczqTKMnlQpmHC5C0VBwNQUoq7+JWlbQVjr76CMsGcrHV4Cq3xPK
xiEzKr/0HJg=
=8R5Q
-END PGP SIGNATURE-
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Gael Varoquaux]

On Sun, Apr 13, 2008 at 12:31:08PM -0400, Stephen Waterbury wrote:
> What I am proposing:

> 1)  the OS comes with its own "system Python", which is installed
> not as the "python" package, but as some OS-required package
> (maybe call it "system-python" or something) and it goes into
> /usr/system/bin/python or whatever -- it doesn't matter what the
> path is as long as it's not /usr/bin or anything on the default
> path.  And system utilities that are python scripts should have
> their own system-specific, hard-coded shebang line.

> 2)  separately from the "system Python", the available packages
> shown by the system's package manager include one or more "python.x"
> packages which are python interpreters that the user or sysadmin can
> optionally install, and which go into /usr.  And the system package
> manager -- e.g., apt on Debian/Ubuntu systems) would have all its usual
> nicely-packaged python apps (python-this, python-that, ...) that would
> also install into /usr and use the nicely-packaged python (not to be
> confused with the "system Python" of 1).

OK. I am starting to see what you mean. I agree it does make sense.

It seems to me that you are bringing in a distinction between "system
Python scripts" and user Python script. For me the system Python scripts
should live in "/bin" and use the system Python, and the users should
live in "/usr/bin" and use "/usr/bin/env python". But that's just me.

Inspecting my boxes did show that this is quite close to the way it is
already on Debian systems. I don't have accounts on other kind of Unix,
so I can't see how it is done elsewhere.

Cheers,

Gaël
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 13, 2008, at 8:04 AM, Gael Varoquaux wrote:
> On Sun, Apr 13, 2008 at 07:59:21AM -0400, Barry Warsaw wrote:
>> On Apr 12, 2008, at 9:41 PM, Stephen Waterbury wrote:
>
>>> I used to always set up my own Python[s] in /usr/local
>>> and put that first in my PATH, but I have gotten lazy lately, and
>>> sometimes it will bite me. ;)
>
>> On Debian and derivatives (e.g. Ubuntu) you might have even more fun.
>> They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of
>> the system python*!  This means that you can break your system Python
>> by installing a version of Python from source and then distutil'ing
>> things into there.  Astoundingly, this is promoted as a feature.
>
> I want it like that. You are confusing /opt and /usr/local.
>
> This is the way I expect things to work. I do not want to install my  
> own
> packages in "/usr/lib/pythonX.Y/site-packages". This is for apt to  
> deal
> with, not for me.

Actually, the solution that I believe is a good compromise is to find  
some other path in /usr/local to augment the system Python's sys.path  
with.  All I'm saying is that Python itself uses /usr/local/lib/ 
pythonX.Y/site-packages as the default from-source path, so if Debian  
wants a /usr/local path, it can pick some other subdirectory path and  
still meet its goals.  BTW, I believe Debian is unique here.  I talked  
to the Fedora guys and I've talked to a few Gentoo guys and both  
seemed surprised by Debian's policy here.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSAI4A3EjvBPtnXfVAQLeagP/aCKr6WL+qvvM8vhABFxJDBbOJw1hQUQT
fCUwL3bZ21a6iKiHLv5mdVBfaFjcqEmnbGqizUmTgnTuG+SaUXHNqBBG2lDCTZUF
fNwWThN/TRtqO5OdknqFcfTQARtBE+YN52CpugjSmRrudZtAAdslWds8HnUP3nlG
kN9J0TsEo1E=
=DDbJ
-END PGP SIGNATURE-
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Stephen Waterbury]

Stephen Waterbury wrote:

Oops, my email client doesn't detect unbalanced parens -- typo here
(what I get for too-complicated paren/double-dash-mixing ;):

> optionally install, and which go into /usr.  And the system package
> manager -- e.g., apt on Debian/Ubuntu systems) would have all its usual
   ^ should be "--"
> nicely-packaged python apps (python-this, python-that, ...) that would
> also install into /usr and use the nicely-packaged python (not to be
> confused with the "system Python" of 1).

Steve
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Stephen Waterbury]

Gael Varoquaux wrote:
> On Sun, Apr 13, 2008 at 11:16:57AM -0400, Stephen Waterbury wrote:
>>> On Debian and derivatives (e.g. Ubuntu) you might have even more fun.  
>>> They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of the 
>>> system python*!  This means that you can break your system Python by 
>>> installing a version of Python from source and then distutil'ing things 
>>> into there.  Astoundingly, this is promoted as a feature.
> 
>> That *is* astounding.  I've been using Ubuntu for several years now,
>> and I blush to admit I never noticed that until just the other day when
>> I tried installing Python 2.6 from source (into the default /usr/local
>> location, of course) and it broke all my running web stuff, so I hastily
>> removed it -- sheesh!
> 
>> As I mentioned, I've been "lazy" about using the system Python for my
>> own apps and development, but I would feel much more comfortable if
>> the system Python had its own space.
> 
>>> I've reported bugs on this and had discussions with some of the Debian 
>>> Python packaging folks.  I'm hoping that we'll find a solution that 
>>> doesn't collide with a from-source default Python build.

> Well, I am not too happy about what I hear here. It seems to me as if
> Ubuntu is headed the macOS X way, where (it seems) that a second Python
> needs to be installed on top of the system Python to add modules to it. I
> know it is not exactly the case, but this change is _really_ going to
> confuse people and I can this the mailing lists of module developper
> pilling up with requests for help. There needs to be a way for the user
> to install his own modules and keep using the system Python.

I think you misunderstand my proposal, Gael ...

You and I are using "system Python" to mean different things.
In my proposal, *the* "system Python" and a packaged Python
installed using the system's package manager would be separate
things (and may or may not be the same version of Python)!

What I am proposing:

1)  the OS comes with its own "system Python", which is installed
not as the "python" package, but as some OS-required package
(maybe call it "system-python" or something) and it goes into
/usr/system/bin/python or whatever -- it doesn't matter what the
path is as long as it's not /usr/bin or anything on the default
path.  And system utilities that are python scripts should have
their own system-specific, hard-coded shebang line.

2)  separately from the "system Python", the available packages
shown by the system's package manager include one or more "python.x"
packages which are python interpreters that the user or sysadmin can
optionally install, and which go into /usr.  And the system package
manager -- e.g., apt on Debian/Ubuntu systems) would have all its usual
nicely-packaged python apps (python-this, python-that, ...) that would
also install into /usr and use the nicely-packaged python (not to be
confused with the "system Python" of 1).

Steve
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Gael Varoquaux]

On Sun, Apr 13, 2008 at 11:16:57AM -0400, Stephen Waterbury wrote:
> > On Debian and derivatives (e.g. Ubuntu) you might have even more fun.  
> > They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of the 
> > system python*!  This means that you can break your system Python by 
> > installing a version of Python from source and then distutil'ing things 
> > into there.  Astoundingly, this is promoted as a feature.

> That *is* astounding.  I've been using Ubuntu for several years now,
> and I blush to admit I never noticed that until just the other day when
> I tried installing Python 2.6 from source (into the default /usr/local
> location, of course) and it broke all my running web stuff, so I hastily
> removed it -- sheesh!

> As I mentioned, I've been "lazy" about using the system Python for my
> own apps and development, but I would feel much more comfortable if
> the system Python had its own space.

> > I've reported bugs on this and had discussions with some of the Debian 
> > Python packaging folks.  I'm hoping that we'll find a solution that 
> > doesn't collide with a from-source default Python build.

Well, I am not too happy about what I hear here. It seems to me as if
Ubuntu is headed the macOS X way, where (it seems) that a second Python
needs to be installed on top of the system Python to add modules to it. I
know it is not exactly the case, but this change is _really_ going to
confuse people and I can this the mailing lists of module developper
pilling up with requests for help. There needs to be a way for the user
to install his own modules and keep using the system Python. I think it
is a very bad idea to do it in /usr. Yes, you can teach your users to add
things to their PYTHONPATH, but this put one additional thing to learn
for people who just want to get things done. I think users are going to
hate this.

Maybe something less drastic can be done, by making sure that the
/usr/local is far in the PYTHONPATH, that way packages installed in
/usr/local do not override the system packages. Of course setuptools will
break this, because it adds itsef to front of the PYTHONPATH, and totally
break the PYTHONPATH semantics (Grrr). 

I still think you guys have it wrong, and if you want a new Python
install, you do it in /opt. For me /usr/local is for user programs that
cooperate for system programs.

My 2 cents,

Gaël
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Stephen Waterbury]

Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Apr 12, 2008, at 9:41 PM, Stephen Waterbury wrote:
>>
>> I used to always set up my own Python[s] in /usr/local
>> and put that first in my PATH, but I have gotten lazy lately, and
>> sometimes it will bite me. ;)
> 
> On Debian and derivatives (e.g. Ubuntu) you might have even more fun.  
> They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of the 
> system python*!  This means that you can break your system Python by 
> installing a version of Python from source and then distutil'ing things 
> into there.  Astoundingly, this is promoted as a feature.

That *is* astounding.  I've been using Ubuntu for several years now,
and I blush to admit I never noticed that until just the other day when
I tried installing Python 2.6 from source (into the default /usr/local
location, of course) and it broke all my running web stuff, so I hastily
removed it -- sheesh!

As I mentioned, I've been "lazy" about using the system Python for my
own apps and development, but I would feel much more comfortable if
the system Python had its own space.

> I've reported bugs on this and had discussions with some of the Debian 
> Python packaging folks.  I'm hoping that we'll find a solution that 
> doesn't collide with a from-source default Python build.

Thanks for fighting the good fight, Barry -- hang in there!
Maybe you can push for my "radical" solution.  :)

Steve
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Stephen Waterbury]

Gael Varoquaux wrote:
> On Sun, Apr 13, 2008 at 07:59:21AM -0400, Barry Warsaw wrote:
>> On Apr 12, 2008, at 9:41 PM, Stephen Waterbury wrote:
> 
>>> I used to always set up my own Python[s] in /usr/local
>>> and put that first in my PATH, but I have gotten lazy lately, and
>>> sometimes it will bite me. ;)
> 
>> On Debian and derivatives (e.g. Ubuntu) you might have even more fun.
>> They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of
>> the system python*!  This means that you can break your system Python
>> by installing a version of Python from source and then distutil'ing
>> things into there.  Astoundingly, this is promoted as a feature.
> 
> I want it like that. You are confusing /opt and /usr/local.

Heh ... that shows my Berkeley roots -- I'm not confused,
I'm just an old SunOS guy still in denial about that damn SysV stuff
that Solaris brought in, like using /opt instead of /usr/local --
bah, humbug!  The OS has /usr; /usr/local is *mine* dammit!  ;)  

Steve
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Stephen Waterbury]

Gael Varoquaux wrote:
> On Sat, Apr 12, 2008 at 09:41:08PM -0400, Stephen Waterbury wrote:
>>> These are all broken and you should report bugs on them.  I have  
>>> reported many for Ubuntu.  A system application should only ever  
>>> depend on the system Python (or interpreter), never on the whims of  
>>> your $PATH.
> 
>> I agree with Barry here -- I would even go further and say that
>> the Python used by system apps (i.e., apps that the OS depends on)
>> should be separate and should not be on the default PATH (so the user
>> can't use it accidentally), and no non-system apps should use the
>> system Python unless specifically installed by the user or sysadmin
>> into the system Python's area.
> 
> I agree with you, and not with Barry that all these are broken. If you
> look at the apps that use "#!/usr/bin/env", they are all pretty
> non-system apps, like for instance "f2py". I think it is good that these
> apps use the default python: I don't want to have f2py to be running for
> another python than my default one. I am actually quite surprised to see
> that ipython is installed with a hardcoded path to /usr/bin/python.
> 
> Anyway, I am not going to bug report anything, as my system works just
> fine, thank you.

Yes, your luck holds -- as does mine, for now ... but since Barry
works for Canonical (besides being Python's new Release Manager),
he has a civic responsibility to report Ubuntu Python bugs even if
his own system works ... and since that can be quite time-consuming,
I can't blame him for trying to recruit some help ... ;)

Steve
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 13, 2008, at 5:50 AM, Gael Varoquaux wrote:
> On Sat, Apr 12, 2008 at 09:41:08PM -0400, Stephen Waterbury wrote:
>>> These are all broken and you should report bugs on them.  I have
>>> reported many for Ubuntu.  A system application should only ever
>>> depend on the system Python (or interpreter), never on the whims of
>>> your $PATH.
>
>> I agree with Barry here -- I would even go further and say that
>> the Python used by system apps (i.e., apps that the OS depends on)
>> should be separate and should not be on the default PATH (so the user
>> can't use it accidentally), and no non-system apps should use the
>> system Python unless specifically installed by the user or sysadmin
>> into the system Python's area.
>
> I agree with you, and not with Barry that all these are broken. If you
> look at the apps that use "#!/usr/bin/env", they are all pretty
> non-system apps, like for instance "f2py". I think it is good that  
> these
> apps use the default python: I don't want to have f2py to be running  
> for
> another python than my default one. I am actually quite surprised to  
> see
> that ipython is installed with a hardcoded path to /usr/bin/python.
>
> Anyway, I am not going to bug report anything, as my system works just
> fine, thank you.

I'm not sure how you can disagree with me and not with Steve since he  
and I agree the system apps are broken. ;)  Oh well, doesn't matter.

Steve has a very interesting idea though, and it makes sense to me.   
I'm not sure where in the FHS you'd put that, but it makes sense for  
Python-written system apps to use the hidden Python and for /usr/bin/ 
python to be one that users can play with.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSAH3jHEjvBPtnXfVAQKIJAP/WWE6i1pjpFJU3Z0mT3AiYeIKZjTfVXjV
jC0DAgGj9AWS9TS1eGYWntb65C3ibZK2vsFjkr4Zg32yx1Dl2qvOfQ3yPD5+z7k5
pLP+LfP1U80HDl2poPRJCetnwV/F29IJpEHgNnWZboqrRrPxJlD3WI8L9D4gECP5
I19vl6e/IVo=
=3/Pm
-END PGP SIGNATURE-
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Gael Varoquaux]

On Sun, Apr 13, 2008 at 07:59:21AM -0400, Barry Warsaw wrote:
> On Apr 12, 2008, at 9:41 PM, Stephen Waterbury wrote:

> > I used to always set up my own Python[s] in /usr/local
> > and put that first in my PATH, but I have gotten lazy lately, and
> > sometimes it will bite me. ;)

> On Debian and derivatives (e.g. Ubuntu) you might have even more fun.
> They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of
> the system python*!  This means that you can break your system Python
> by installing a version of Python from source and then distutil'ing
> things into there.  Astoundingly, this is promoted as a feature.

I want it like that. You are confusing /opt and /usr/local.

This is the way I expect things to work. I do not want to install my own
packages in "/usr/lib/pythonX.Y/site-packages". This is for apt to deal
with, not for me.

Gaël

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 12, 2008, at 9:41 PM, Stephen Waterbury wrote:
>
> I used to always set up my own Python[s] in /usr/local
> and put that first in my PATH, but I have gotten lazy lately, and
> sometimes it will bite me. ;)

On Debian and derivatives (e.g. Ubuntu) you might have even more fun.   
They put /usr/local/lib/pythonX.Y/site-packages on the sys.path *of  
the system python*!  This means that you can break your system Python  
by installing a version of Python from source and then distutil'ing  
things into there.  Astoundingly, this is promoted as a feature.

I've reported bugs on this and had discussions with some of the Debian  
Python packaging folks.  I'm hoping that we'll find a solution that  
doesn't collide with a from-source default Python build.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSAH1mnEjvBPtnXfVAQJAvAP/S1p03Jlq73fZB4H6Qt7cH/qXpInQ4G7i
VDMdH0yxZ3Fih8LG/eFcvpu0YCI7iHWtct+h2GXA/gUVPlgWxwJDE2Ahixg9MNS3
faETU1DNqJb4oUbwjZD/FzwLCGRXp/17s4+Q2JX4YaOvShsVeS+F3Kr+3zwfDL0m
hrMRfaJTYSE=
=a8MZ
-END PGP SIGNATURE-
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] shebang line modified by setuptools

[Gael Varoquaux]

On Sat, Apr 12, 2008 at 09:41:08PM -0400, Stephen Waterbury wrote:
> > These are all broken and you should report bugs on them.  I have  
> > reported many for Ubuntu.  A system application should only ever  
> > depend on the system Python (or interpreter), never on the whims of  
> > your $PATH.

> I agree with Barry here -- I would even go further and say that
> the Python used by system apps (i.e., apps that the OS depends on)
> should be separate and should not be on the default PATH (so the user
> can't use it accidentally), and no non-system apps should use the
> system Python unless specifically installed by the user or sysadmin
> into the system Python's area.

I agree with you, and not with Barry that all these are broken. If you
look at the apps that use "#!/usr/bin/env", they are all pretty
non-system apps, like for instance "f2py". I think it is good that these
apps use the default python: I don't want to have f2py to be running for
another python than my default one. I am actually quite surprised to see
that ipython is installed with a hardcoded path to /usr/bin/python.

Anyway, I am not going to bug report anything, as my system works just
fine, thank you.

Gaël
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig