Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

2008-10-07 Thread Phillip J. Eby

At 10:07 AM 10/7/2008 -0400, Tarek Ziadé wrote:

The -m feature of setuptools is nice, but it activates one version at
a time, and
this is globlal to Python unless each application is handling the
version switch,
wich is pretty heavy.


With or without the -m switch, scripts installed by setuptools will 
find the version they are specified to use, without the user needing 
to do anything.  So, you can have a default version of an egg (used 
by the interpreter and non-setuptools scripts), and then some 
non-default versions that are used by scripts.


zc.buildout and virtualenv also have their own ways of accomplishing 
the same thing, e.g., by hardcoding paths in an installed script.


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


Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

2008-10-07 Thread Tarek Ziadé
On Tue, Oct 7, 2008 at 2:42 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
 At 10:07 AM 10/7/2008 -0400, Tarek Ziadé wrote:

 The -m feature of setuptools is nice, but it activates one version at
 a time, and
 this is globlal to Python unless each application is handling the
 version switch,
 wich is pretty heavy.

 With or without the -m switch, scripts installed by setuptools will find the
 version they are specified to use, without the user needing to do anything.
  So, you can have a default version of an egg (used by the interpreter and
 non-setuptools scripts), and then some non-default versions that are used by
 scripts.

 zc.buildout and virtualenv also have their own ways of accomplishing the
 same thing, e.g., by hardcoding paths in an installed script.

in a plain python setup,

If foo 1.2 is the default, and a package wants use foo 1.4,
it needs to specifically call pkg_resources.require() in the code, to
activate it in sys.path
before importing foo in the code.

Since each package can list with setuptools its dependencies with
versions in install_requires,
how hard  would it be to automatically call the right require()
calls when the package is used ?

Tarek
-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig


Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

2008-10-07 Thread Ian Bicking

Tarek Ziadé wrote:

On Tue, Oct 7, 2008 at 2:42 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:

At 10:07 AM 10/7/2008 -0400, Tarek Ziadé wrote:

The -m feature of setuptools is nice, but it activates one version at
a time, and
this is globlal to Python unless each application is handling the
version switch,
wich is pretty heavy.

With or without the -m switch, scripts installed by setuptools will find the
version they are specified to use, without the user needing to do anything.
 So, you can have a default version of an egg (used by the interpreter and
non-setuptools scripts), and then some non-default versions that are used by
scripts.

zc.buildout and virtualenv also have their own ways of accomplishing the
same thing, e.g., by hardcoding paths in an installed script.


in a plain python setup,

If foo 1.2 is the default, and a package wants use foo 1.4,
it needs to specifically call pkg_resources.require() in the code, to
activate it in sys.path
before importing foo in the code.

Since each package can list with setuptools its dependencies with
versions in install_requires,
how hard  would it be to automatically call the right require()
calls when the package is used ?


require() is recursive, so as long as the original script is explicitly 
loaded (e.g., from a binary script, or something that loads eggs/entry 
points) then the proper versions will be loaded.  Though as far as I 
know, pkg_resources won't remove other versions of the egg from the 
path, so it only works if there are no active versions of the eggs. 
Which isn't how many people install packages, so this feature of 
require() doesn't get used for much of anything (at least that I've seen).


I'll also note that the require in setuptools-generated scripts causes 
pretty frequent problems for people, all to support this multi-version 
feature that no one really uses.


An example of an easy way to cause the problem, if you do: python 
setup.py develop; svn up; python setup.py egg_info it'll break any 
scripts, or if you install a script in an unusual location, or use 
$PYTHONPATH but don't set $PATH so that you get an unexpected script 
that doesn't match your libraries -- since pyinstall is using 
--single-version-externally-managed, I kind of wish I could easily turn 
off the require() as well (I could monkeypatch setuptools to remove it, 
but I've been burned by going down that path before).



--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig


Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

2008-10-07 Thread Phillip J. Eby

At 02:58 PM 10/7/2008 -0400, Tarek Ziadé wrote:

On Tue, Oct 7, 2008 at 2:42 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
 At 10:07 AM 10/7/2008 -0400, Tarek Ziadé wrote:

 The -m feature of setuptools is nice, but it activates one version at
 a time, and
 this is globlal to Python unless each application is handling the
 version switch,
 wich is pretty heavy.

 With or without the -m switch, scripts installed by setuptools 
will find the

 version they are specified to use, without the user needing to do anything.
  So, you can have a default version of an egg (used by the interpreter and
 non-setuptools scripts), and then some non-default versions that 
are used by

 scripts.

 zc.buildout and virtualenv also have their own ways of accomplishing the
 same thing, e.g., by hardcoding paths in an installed script.

in a plain python setup,

If foo 1.2 is the default, and a package wants use foo 1.4,
it needs to specifically call pkg_resources.require() in the code, to
activate it in sys.path
before importing foo in the code.


You can't un-default the default, actually.  If there's a default, it 
can't be replaced once pkg_resources has been imported.




Since each package can list with setuptools its dependencies with
versions in install_requires,
how hard  would it be to automatically call the right require()
calls when the package is used ?


This is already done by setuptools-generated scripts.  Same for 
zc.buildout and virtualenv, they just do it differently. 


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


Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

2008-10-03 Thread Chris Withers

Phillip J. Eby wrote:
I think we need a standard for tools 
interop (ala WSGI), not implementation tweaks for the existing tools.  


Agreed.


4/ let's change PyPI to make it work with the new metadata and to
enforce a few things

Enforcements:
- a binary distribution cannot be uploaded if a source distrbution
has not been previously provided for the version


Note that this doesn't allow closed-source packages to be uploaded; thus 
it would need to be a warning, rather than a requirement.


This is an important point. We can't assume any one repository will have 
all needed packages.


It could only do this for specific binaries, since dependencies can be 
dynamic.


They should not be dynamic :-(

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig


Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

2008-10-03 Thread Phillip J. Eby

At 04:18 PM 10/3/2008 +0100, Chris Withers wrote:

Phillip J. Eby wrote:
It could only do this for specific binaries, since dependencies can 
be dynamic.


They should not be dynamic :-(


Too bad. They are, because they have to be in order to support more 
than one platform and/or Python version from the same source base.


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


Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

2008-10-01 Thread Fred Drake
On Wed, Oct 1, 2008 at 8:10 AM, Tarek Ziadé [EMAIL PROTECTED] wrote:
 8/ the requires-python field is rarely used by people, so unless you
 try the package, you don't know when it is a source
distribution, if it is going to run on various python versions.

What requires-python field?

I don't see this documented for distutils or setuptools.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig