Re: [Distutils] bootstrap 1.5.2, python2.6 and DistributionNotFound
On Tue, Sep 10, 2013 at 07:44:05AM +0200, Alessandro Dentella wrote:
> Hi,
>
> I'm having problems using buildout on squeeze (that uses python 2.6). On
> ubuntu 12.10 (that uses python2.7) I have no problems.
>
> I'm still usig buildout 1.5.2 as I need a recipe for virtual env that is
> not yet available for buildout 2.+ (tl.buildout_virtual_python).
BTW buildout 1.7.1 exists, and should be compatible with 1.5.x.
Be sure you're using the latest version of pre-2.0 bootstrap.py by
downloading it from http:/downloads.buildout.org/1/bootstrap.py
> When executing "python bootstrap" I'm getting:
>
>pkg_resources.DistributionNotFound: distribute
>
> This problem occurs also with a very simple conf that I found on
> the net when I started lunar.tar.gz, I uploaded the version I'm using here
> [1] after substituting bootstrap.py with a recent one.
>
> Here what I get:
>
>root@fw1-vpn-saa:/tmp/lunar/lunar# python bootstrap.py
>Downloading
> http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
>Creating directory '/tmp/lunar/lunar/bin'.
>Creating directory '/tmp/lunar/lunar/parts'.
>Creating directory '/tmp/lunar/lunar/eggs'.
>Creating directory '/tmp/lunar/lunar/develop-eggs'.
>Getting distribution for 'setuptools'.
>/usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown
> distribution option: 'src_root'
> warnings.warn(msg)
>Got setuptools 1.1.4.
>Generated script '/tmp/lunar/lunar/bin/buildout'.
>root@fw1-vpn-saa:/tmp/lunar/lunar# bin/buildout
>Traceback (most recent call last):
> File "bin/buildout", line 17, in
>import zc.buildout.buildout
> File
> "/tmp/lunar/lunar/eggs/zc.buildout-1.7.1-py2.6.egg/zc/buildout/buildout.py",
> line 40, in
>import zc.buildout.download
> File
> "/tmp/lunar/lunar/eggs/zc.buildout-1.7.1-py2.6.egg/zc/buildout/download.py",
> line 20, in
>from zc.buildout.easy_install import realpath
> File
> "/tmp/lunar/lunar/eggs/zc.buildout-1.7.1-py2.6.egg/zc/buildout/easy_install.py",
> line 31, in
>import setuptools.package_index
> File
> "/usr/local/lib/python2.6/dist-packages/distribute-0.6.24-py2.6.egg/setuptools/package_index.py",
> line 157, in
>sys.version[:3], require('distribute')[0].version
> File "build/bdist.linux-i686/egg/pkg_resources.py", line 673, in require
>
> File "build/bdist.linux-i686/egg/pkg_resources.py", line 576, in resolve
>dist = best[req.key] = env.best_match(req, self, installer)
>pkg_resources.DistributionNotFound: distribute
>
>
> If I use 'python bootstrap -d' that uses distribute, it will raise this
> error even on ubuntu 12.10/python2.7:
>
>
>root@fw1-vpn-saa:/tmp/lunar/lunar# python bootstrap.py -d
>Downloading
> http://pypi.python.org/packages/source/d/distribute/distribute-0.6.49.tar.gz
>Extracting in /tmp/tmpIsQPGq
>Now working in /tmp/tmpIsQPGq/distribute-0.6.49
>Building a Distribute egg in /tmp/tmpkqSNaa
>/tmp/tmpkqSNaa/distribute-0.6.49-py2.6.egg
>Getting distribution for 'distribute'.
>warning: install_lib: 'build/lib.linux-i686-2.6' does not exist -- no
> Python modules to install
>Got distribute 0.7.3.
>While:
> Bootstrapping.
>
>An internal error occurred due to a bug in either zc.buildout or in a
>recipe being used:
>Traceback (most recent call last):
> File
> "/tmp/tmpkqSNaa/zc.buildout-1.7.1-py2.6.egg/zc/buildout/buildout.py", line
> 1866, in main
>getattr(buildout, command)(args)
> File
> "/tmp/tmpkqSNaa/zc.buildout-1.7.1-py2.6.egg/zc/buildout/buildout.py", line
> 399, in bootstrap
>ws.require('zc.buildout')
> File "build/bdist.linux-i686/egg/pkg_resources.py", line 698, in require
>needed = self.resolve(parse_requirements(requirements))
> File "build/bdist.linux-i686/egg/pkg_resources.py", line 596, in resolve
>raise DistributionNotFound(req)
>DistributionNotFound: setuptools>=0.7
>
>
> Any help is appreciated
Use a virtualenv to give both distribute and setuptools >= 0.7 to
buildout:
virtualenv env
env/bin/pip install -U setuptools
env/bin/python bootstrap.py
bin/buildout
This works with both buildout 1.x and 2.x.
Marius Gedminas
--
Writing like a l33t script kiddie hax0r is the absolute kiss of death and
guarantees you will receive nothing but stony silence (or, at best, a heaping
helping of scorn and sarcasm) in return.
-- ESR (http://www.tuxedo.org/~esr/faqs/smart-questions.html)
signature.asc
Description: Digital signature
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] bootstrap 1.5.2, python2.6 and DistributionNotFound
Hi,
I'm having problems using buildout on squeeze (that uses python 2.6). On
ubuntu 12.10 (that uses python2.7) I have no problems.
I'm still usig buildout 1.5.2 as I need a recipe for virtual env that is
not yet available for buildout 2.+ (tl.buildout_virtual_python).
When executing "python bootstrap" I'm getting:
pkg_resources.DistributionNotFound: distribute
This problem occurs also with a very simple conf that I found on
the net when I started lunar.tar.gz, I uploaded the version I'm using here
[1] after substituting bootstrap.py with a recent one.
Here what I get:
root@fw1-vpn-saa:/tmp/lunar/lunar# python bootstrap.py
Downloading
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
Creating directory '/tmp/lunar/lunar/bin'.
Creating directory '/tmp/lunar/lunar/parts'.
Creating directory '/tmp/lunar/lunar/eggs'.
Creating directory '/tmp/lunar/lunar/develop-eggs'.
Getting distribution for 'setuptools'.
/usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution
option: 'src_root'
warnings.warn(msg)
Got setuptools 1.1.4.
Generated script '/tmp/lunar/lunar/bin/buildout'.
root@fw1-vpn-saa:/tmp/lunar/lunar# bin/buildout
Traceback (most recent call last):
File "bin/buildout", line 17, in
import zc.buildout.buildout
File
"/tmp/lunar/lunar/eggs/zc.buildout-1.7.1-py2.6.egg/zc/buildout/buildout.py",
line 40, in
import zc.buildout.download
File
"/tmp/lunar/lunar/eggs/zc.buildout-1.7.1-py2.6.egg/zc/buildout/download.py",
line 20, in
from zc.buildout.easy_install import realpath
File
"/tmp/lunar/lunar/eggs/zc.buildout-1.7.1-py2.6.egg/zc/buildout/easy_install.py",
line 31, in
import setuptools.package_index
File
"/usr/local/lib/python2.6/dist-packages/distribute-0.6.24-py2.6.egg/setuptools/package_index.py",
line 157, in
sys.version[:3], require('distribute')[0].version
File "build/bdist.linux-i686/egg/pkg_resources.py", line 673, in require
File "build/bdist.linux-i686/egg/pkg_resources.py", line 576, in resolve
dist = best[req.key] = env.best_match(req, self, installer)
pkg_resources.DistributionNotFound: distribute
If I use 'python bootstrap -d' that uses distribute, it will raise this
error even on ubuntu 12.10/python2.7:
root@fw1-vpn-saa:/tmp/lunar/lunar# python bootstrap.py -d
Downloading
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.49.tar.gz
Extracting in /tmp/tmpIsQPGq
Now working in /tmp/tmpIsQPGq/distribute-0.6.49
Building a Distribute egg in /tmp/tmpkqSNaa
/tmp/tmpkqSNaa/distribute-0.6.49-py2.6.egg
Getting distribution for 'distribute'.
warning: install_lib: 'build/lib.linux-i686-2.6' does not exist -- no Python
modules to install
Got distribute 0.7.3.
While:
Bootstrapping.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File "/tmp/tmpkqSNaa/zc.buildout-1.7.1-py2.6.egg/zc/buildout/buildout.py",
line 1866, in main
getattr(buildout, command)(args)
File "/tmp/tmpkqSNaa/zc.buildout-1.7.1-py2.6.egg/zc/buildout/buildout.py",
line 399, in bootstrap
ws.require('zc.buildout')
File "build/bdist.linux-i686/egg/pkg_resources.py", line 698, in require
needed = self.resolve(parse_requirements(requirements))
File "build/bdist.linux-i686/egg/pkg_resources.py", line 596, in resolve
raise DistributionNotFound(req)
DistributionNotFound: setuptools>=0.7
Any help is appreciated
Thanks
sandro
[1] http://www.e-den.it/misc/lunar-sd.tar.gz
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Specification for a local PyPI simple index
On Mon, Sep 9, 2013 at 10:54 AM, Paul Moore wrote: > Is the spec at > http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api > still the definitive version of what must be provided for a local PyPI > index (for use by something like pip)? Or is there a more up to date > version anywhere? That spec is for setuptools 0.6. Later versions should have changed this documentation (in the PyPA repository) if they changed the protocol, but I don't know if anybody's actually keeping tabs on that. > For example, are MD5 signatures still the only supported version? I > thought we were moving away from MD5. Hm. Yeah, a quick glance at https://bitbucket.org/pypa/setuptools/src shows the docs unchanged, so whoever added the non-MD5 support forgot to check the docs for references to md5. > And while I haven't really > followed the offsite hosting changes, are the > rel="homepage"/rel="download" links still as stated? (I think I'd want > rel="download" on everything as I only expect to provide URLs for > actual package content). The meaning of re="downloadl" values is, "spider this page for download links", not "this is a link to download".Links to download are identified by inspecting a link, not retrieving it. The only reason the rel tags exist is to mark URLs as spiderable. > Also, how definitive is item 7, which states that the root URL must > result in a page containing all projects, but it can be omitted if > case-insensitive safe_name() matching of projects is implemented? It's definitive for easy_install. The only reason easy_install retrieves the root URL is if a requested package isn't found; the reason it does this is to catch alternative spellings due to case-sensitivity and/or differences in punctuation folding. If you can interpret easy_install's initial GET as a package requirement string (w/case- and punctuation-insensitivity via pkg_resources.safe_name()) rather than as an exact string match, then failure to match would produce the same failure to match on a full package listing, so there's no point having the full listing appear. It's strictly a fallback intended for "dumb" package indexes that simply consist of a directory tree and a web server providing directory listings. (I think it can even work with an FTP site, but it's been a while since I worked on that code.) > The > reason I ask is that providing a full listing will be somewhat costly > in my application, but providing case-insensitive matching should be > doable (actually, I'm not sure yet what's feasible, but I want to know > whether it's worth my time even investigating). I don't know what pip does, but I assume that it's probably true of all package managers that either their targeted request succeeds or fails, and then they either request the full listing or they don't. So... the only possible way not providing the full list would be if some (foolish) package manager always began by requesting a full package listing. It's possible there are tools that wish to obtain a full listing and use the base URL for that... but AFAICT it would be a foolish thing to do if you're just trying to install packages. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Specification for a local PyPI simple index
On 9 September 2013 16:27, Donald Stufft wrote: > Does that help? It does. A lot. Many thanks for that, I could probably have worked most of it out but you've saved me a decent chunk of time. Cheers, Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Specification for a local PyPI simple index
On Sep 9, 2013, at 11:15 AM, Paul Moore wrote: > On 9 September 2013 16:11, Donald Stufft wrote: >> It might match what easy_install looks for but it's not up to date. I think >> it's >> still written as if the simple index had not been created. That being said >> it'll probably mostly work. One of my steps I want to do with warehouse >> is actually get this codified. > > Sigh. That's what I thought :-( > > Particularly as I don't actually want it to work with easy_install, > but rather with pip. OK, I guess I'll just have to go with what that > page and reverse-engineer from there. Warehouse (or at least something > with an actual *spec*) can't come too soon for me... > > Thanks for the clarifications on the other points, too. > > Paul It's not that complicated. Assuming an --index-url of https://pypi.python.org/simple/ ``pip install foo`` will look at 1. https://pypi.python.org/simple/foo/ 2. https://pypi.python.org/simple/ ``pip install foo==1.0`` will look at 1. https://pypi.python.org/simple/foo/1.0/ 2. https://pypi.python.org/simple/foo/ 3. https://pypi.python.org/simple/ It will stop once it finds a page that doesn't error or 404 (so typically it only looks at /foo/). Once it has a page it looks for html links and essentially categorizes them into "installable" and "not installable". It's installable if it "looks" like a package url (the url looks like it's a file that matches the naming scheme). Then it looks at any rel = "download" or rel = "homepage" and if they are not installable links it will also fetch their HTML and do the same process of looking for "installable" links. Once it has a list of all the installable links for a page it selects the highest version one matching the spec we have and installs it. If there is a meta tag for api version and that version is >= 2 then that triggers the new external stuff which is opt in for pip 1.4 and opt out in pip 1.5. This allows an index server to specify "this file is hosted by me" by adding a rel="internal" to links to self hosted files. In pip 1.5 (and opt in for 1.4) pip will only install internal files (for servers with an api version metatag) unless the proper flags were passed to the command. There is a gotcha where setuptools (and pip still, though I want to deprecate it) also looks for a an extract string that looks like http://peak.telecommunity.com/DevCenter/EasyInstall#backward-compatibility which can be inside HTML comments. Does that help? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Specification for a local PyPI simple index
On 9 September 2013 16:11, Donald Stufft wrote: > It might match what easy_install looks for but it's not up to date. I think > it's > still written as if the simple index had not been created. That being said > it'll probably mostly work. One of my steps I want to do with warehouse > is actually get this codified. Sigh. That's what I thought :-( Particularly as I don't actually want it to work with easy_install, but rather with pip. OK, I guess I'll just have to go with what that page and reverse-engineer from there. Warehouse (or at least something with an actual *spec*) can't come too soon for me... Thanks for the clarifications on the other points, too. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Specification for a local PyPI simple index
On Sep 9, 2013, at 10:54 AM, Paul Moore wrote: > Is the spec at > http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api > still the definitive version of what must be provided for a local PyPI > index (for use by something like pip)? Or is there a more up to date > version anywhere? It might match what easy_install looks for but it's not up to date. I think it's still written as if the simple index had not been created. That being said it'll probably mostly work. One of my steps I want to do with warehouse is actually get this codified. > > For example, are MD5 signatures still the only supported version? I > thought we were moving away from MD5. And while I haven't really > followed the offsite hosting changes, are the > rel="homepage"/rel="download" links still as stated? (I think I'd want > rel="download" on everything as I only expect to provide URLs for > actual package content). MD5s are the only thing supported by PyPI but setuptools 0.9+ (I think?) and pip 1.2+ support sha1, sha256, sha512, etc. > > Also, how definitive is item 7, which states that the root URL must > result in a page containing all projects, but it can be omitted if > case-insensitive safe_name() matching of projects is implemented? The > reason I ask is that providing a full listing will be somewhat costly > in my application, but providing case-insensitive matching should be > doable (actually, I'm not sure yet what's feasible, but I want to know > whether it's worth my time even investigating). This makes stuff like ``pip install django`` when the actual name is Django work. As long as your url matches safe_name it should be fine. > > I'm still thinking about design at the moment, so what I need is far > from decided, but I want to be sure that I'm actually implementing the > correct spec as a starting point! > > Thanks, > Paul > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Specification for a local PyPI simple index
Is the spec at http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api still the definitive version of what must be provided for a local PyPI index (for use by something like pip)? Or is there a more up to date version anywhere? For example, are MD5 signatures still the only supported version? I thought we were moving away from MD5. And while I haven't really followed the offsite hosting changes, are the rel="homepage"/rel="download" links still as stated? (I think I'd want rel="download" on everything as I only expect to provide URLs for actual package content). Also, how definitive is item 7, which states that the root URL must result in a page containing all projects, but it can be omitted if case-insensitive safe_name() matching of projects is implemented? The reason I ask is that providing a full listing will be somewhat costly in my application, but providing case-insensitive matching should be doable (actually, I'm not sure yet what's feasible, but I want to know whether it's worth my time even investigating). I'm still thinking about design at the moment, so what I need is far from decided, but I want to be sure that I'm actually implementing the correct spec as a starting point! Thanks, Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
