Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals
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. "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
Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals
On Wed, Oct 1, 2008 at 3:08 PM, Fred Drake <[EMAIL PROTECTED]> wrote: > 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. The one described here http://www.python.org/dev/peps/pep-0345/ in Metadata 1.2 'Requires-Python' So it can't be used by people at this time, that was a mistake. the new version of [8] could be: 8/ you don't know when it is a source distribution, if it is going to run on various python versions. PEP 345 defines it, but it is not yet implemented in distutils, either in setuptools. and in the proposal parts: 0/ ... + implement the metadata 1.2 from PEP 345, (besides the "requires" metadata) > > > -Fred > > -- > Fred L. Drake, Jr. > "Chaos is the score upon which reality is written." --Henry Miller > -- 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
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
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
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
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
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
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