Steps to re-create
* Set up an environment as per my previous email but without the egg
installed in site-packages.
* Delete the egg from the egg_repository so that the file we expect to
see is missing, but is still indicated in the html file which is used as
the index of the egg repository directory.
* Try to easy install the egg (as in previous example) and take note of
the exception raised.
My error is here:
http://pastebin.com/m36b84d95
I'm guessing that we get a zipimporterror because the stream returned by
the URL fetching fuction is obviously not zip data. However in this case
might it be more appropriate to raise DistributionNotFound or some kind
of special exception that more correctly describes this situation?
Thanks,
Sal
This email does not create a legal relationship between any member of the
Cr=E9dit Agricole group and the recipient or constitute investment advice.
The content of this email should not be copied or disclosed (in whole or
part) to any other person. It may contain information which is
confidential, privileged or otherwise protected from disclosure. If you
are not the intended recipient, you should notify us and delete it from
your system. Emails may be monitored, are not secure and may be amended,
destroyed or contain viruses and in communicating with us such conditions
are accepted. Any content which does not relate to business matters is not
endorsed by us.
Calyon is authorised by the Comit=e9 des Etablissements de Cr=e9dit et des
Entreprises d'Investissement (CECEI) and supervised by the Commission Bancaire
in France and subject to limited regulation by the Financial Services Authority.
Details about the extent of our regulation by the Financial Services Authority
are available from us on request. Calyon is incorporated in France with limited
liability and registered in England & Wales. Registration number: FC008194.
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
This message and/or any attachments is intended for the sole use of its addressee.
If you are not the addressee, please immediately notify the sender and then destroy the message.
As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Crédit Agricole CIB.
All rights reserved.
Ce message et ses pièces jointes est destiné à l'usage exclusif de son destinataire.
Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite.
Le présent message pouvant être altéré à notre insu, CALYON Crédit Agricole CIB ne peut pas être engagé par son contenu.
Tous droits réservés.
I think I've found a bug in the way that setuptools selects whether an
egg specified by file:// url should be installed over an existing
(identical) egg:
To re-create the fault:
* Install the egg of your choice.
* make two local "egg repositories", one with a very long path (e.g.
c:/a/) and one with a very long path
* In each of the egg repositories place a copy of the egg you just
installed, along with an HTML file containing a link to that egg... just
it's filename.
* Try to easy_install the egg with the options "-mv" and set "-f" to
either one of the repositories
When you select a short path for the repository you will notice that the
egg in your site_packages folder is always replaced, you see something
like this:
"Removing
d:\devtools\python24\lib\site-packages\calyon-1.0_r2009_03_12-py2.4-win3
2.egg"
When you select a very long path for the repository you will not see
this message, this is because easy_install leaves the egg unmodified.
I've found out why this happens: The pkg_resources.Environment uses a
hash-tuple to work out the order in which to consider packages to
install. If you are trying to install two identical eggs, the 4th
element of the tuple -len(self.location or '') becomes significant...
longer URLs get preference to shorter URLs.
That on it's own might not seem too bad, but consider the the 2nd value
of the hash-tuple (precedence) is given an identical value of 3 both for
a package which is already installed in pkg_resources and a package
which can already be downloaded from a file:// link. I think a better
default behaviour would be for it to give stuff that is already
installed a higher precedence than stuff which could potentially be
installed.
Hope all of this makes sense!
Sal
This email does not create a legal relationship between any member of the
Cr=E9dit Agricole group and the recipient or constitute investment advice.
The content of this email should not be copied or disclosed (in whole or
part) to any other person. It may contain information which is
confidential, privileged or otherwise protected from disclosure. If you
are not the intended recipient, you should notify us and delete it from
your system. Emails may be monitored, are not secure and may be amended,
destroyed or contain viruses and in communicating with us such conditions
are accepted. Any content which does not relate to business matters is not
endorsed by us.
Calyon is authorised by the Comit=e9 des Etablissements de Cr=e9dit et des
Entreprises d'Investissement (CECEI) and supervised by the Commission Bancaire
in France and subject to limited regulation by the Financial Services Authority.
Details about the extent of our regulation by the Financial Services Authority
are available from us on request. Calyon is incorporated in France with limited
liability and registered in England & Wales. Registration number: FC008194.
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
This message and/or any attachments is intended for the sole use of its addressee.
If you are not the addressee, please immediately notify the sender and then destroy the message.
As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Crédit Agricole CIB.
All rights reserved.
Ce message et ses pièces jointes est destiné à l'usage exclusif de son destinataire.
Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite.
Le présent message pouvant être altéré à notre insu, CALYON Crédit Agricole CIB ne peut pas être engagé par son contenu.
Tous droits réservés.
New submission from Martijn Pieters <mj(a)zopatista.com>:
After upgrading to subversion 1.6, the dreaded unrecognized .svn/entries format
pops up again. The entries format version number is 10, and if I add that to
sdist.entries_finder, things appear to work just fine.
Perhaps the test can be updated to parse the integer and use a >= 9 test on it,
and just assume that future formats will continue to work until proven otherwise?
----------
messages: 253
nosy: mjpieters
priority: bug
status: unread
title: Subversion 1.6 entries format 'unrecognized'
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue64>
_______________________________________________
Hi,
Following one discussion on the python-dev ML, here is one of my
recent frustration with distutils. I have a pure C library (pure meaning
it does not use the python C API in any way) which I want to install so
that other python packages can use it:
from distutils.core import setup
# How to install libfoo.a/foo.lib in say pkg_dir/lib ?
setup(name='yo', libraries=[('foo', {'sources': ['foo.c']})])
I install headers in pkg_dir/include (for example
site-packages/foo/include/foo.h), and I want to install foo lib in
site-packages/foo/lib. I can't easily retrieve the library file in the
build dir from setup.py, so I can't use install_data (and libraries are
not data anyway),
cheers,
David
Suggestions:
Instead of http://pypi.python.org/mirrors how about
http://mirrors.pypi.python.org (or pypimirrors.python.org, etc) --
then the mirror list can be hosted separately, and the likelihood of
both the mirrors and the main PyPI server being down are much lower.
Admittedly, this makes it harder for other indexes to provide their
own mirrors, and the location is just entirely magic. But it seems
like a useful magic.
In the egg-info PEP: "They both add other files in the `EGG-INFO` or
`.egg-info` directory, and
create or modify `.pth` files. `pip` also creates one `.pth` file
per installed package, which may lead to slow initialisation of Python."
I don't believe this is the case. pip zip creates one .pth file for
each zip file, but that's different. pip installs packages flat.
Unless you use -e, which invokes setup.py develop, which I believe
puts the path in easy-install.pth.
Oh, you also use British English; "initialization"! I only notice
that because my spell check is complaining about the quotation ;)
As mentioned in another email, I think RECORD should hold relative
paths (and PJE's "/" suggestion also of course seems reasonable). The
paths should be relative to the .egg-info directory.
"- get_egg_info(pkg_name) -> path or None
Scans all site-packages directories and looks for all `pkg_name.egg-info`
directories. Returns the directory path that contains a PKG-INFO that matches
`pkg_name` for the `name` metadata. Notice that there should be at most
one result. If more than one path matches the pkg_name, a DistutilsError
is raised.
If the directory is not found, returns None."
Currently, if there are multiple paths that might be importable,
whichever one is found first with sys.path is imported, and conflicts
aren't really considered. raising DistutilsError seems like it
changes this.
" filename can be any value found in `distutils.sdist.EGG_INFO_FILES`."
Is there any reason this should be restricted to those filenames?
--
Ian Bicking | http://blog.ianbicking.org
Hi,
I am relatively new to Python and recently had to install 2.6 on a coworker's computer.
Not having a Windows 2.6 exe on the setuptools page of PyPI caused me considerable heartache and hassle.
I eventually found a copy of setuptools-0.6c9.win32.exe which I had managed to build some months ago.
I attach a copy in the hope it might shame someone with more experience into puting it or something better onto PyPI
IMHO this is a major hurdle for a newcomer trying to use packages if the set up utility itself is missing.
Ah! not allowed to attach .exe to this list. Deleted attachment and trying again.
Regards,
Peter Bobroff
I have some confusion over the name .egg-info. From what I understand,
Eggs are a packaging format that contain metadata. But if you take a
Distutils installed package and put a .egg-info file or directory
beside it, that doesn't make the package an Egg, does it?
To add to this confusion, I always associate the Egg format with the
additional metadata fields provided by setuptools. So when I see .egg-
info I always expect that the PKG-INFO will contain an
'install_requires' field, etc. It would be more understandable (to me)
if this directory was named .pkg-info, .metadata, .install or
something. But then I guess that's a somewhat disruptive change for
small gains.
An alternative to bridging the disconnect between the setuptools
metadata fields and the distutils metadata fields would be to add the
setuptools fields to distutils as standard package metadata. Adding
those metadata fields hasn't been propsed yet as it's own PEP, has it?
I guess that PEP would entail a little more work than just managing a
set of fields since PyPI would also need to be updated to display
those fields. But it would be really lovely to be able to see the
'install_requires' field when browsing PyPI - and click on links in
that field to take you to those pakcages PyPI pages. And as an added
bonus if the 'namespace_packages' field was clickable such that the
link took you to a list of all packages which participated in that
namespace, that'd be pretty sweet!
The latest version of stdeb, the automated Debian (and Ubuntu) package
maker, is available for download.
Stdeb takes your Python source (either a tarball or an a directory with
a setup.py script) and turns it into a Debian source package. From
there, it is trivial to turn it into a .deb file.
This version adds support for Ubuntu Jaunty and python2.6 in Debian
experimental by passing the "--install-layout=deb" option to "python
setup.py install".
Also in this release is a bugfix to the autofind-depends feature.
The homepage: http://github.com/astraw/stdeb
Download: http://pypi.python.org/pypi/stdeb/0.3
Hello,
I'm am distributing a package with binary executables which are compiled on
installation. Everything works so far, except that when the binary
executables are copied to the destination that they loose the executable
flag. Here's the code:
--------
#!/usr/bin/env python
from distutils.core import setup
from imp import find_module
from os import system, path
import os
#This is a list of files to install, and where
#(relative to the 'root' dir, where setup.py is)
#You could be more specific.
#find_module('pyraf')
find_module('ephem')
find_module('numpy')
find_module('scipy')
#find_module('SOAPpy')
def makeAll():
curdir=os.getcwd()
srcDir=os.path.join(os.path.dirname(os.path.abspath(__file__)),
'src/pywcs/extutil/src')
os.chdir(srcDir)
os.system('make clean')
os.system('make')
os.chdir(curdir)
makeAll()
setup(name = "pywcs",
version = "0.91",
description = "Collection of tools to use wcs information and fit new
wcs to images",
author = "Wolfgang Kerzendorf",
author_email = "wkerzendorf(a)gmail.com",
url = "http://www.mso.anu.edu.au/~wkerzend/",
#Name the folder where your packages live:
#(If you have other packages (dirs) or modules (py files) then
#put them into the package directory - they will be found
#recursively.)
packages = ['pywcs'],
#'package' package must contain files (see list above)
#I called the package 'package' thus cleverly confusing the whole
issue...
#This dict maps the package name =to=> directories
#It says, package *needs* these files.
package_dir={'':'src'},
package_data = {'pywcs' :
["conf.d/sex.d/*","extutil/src/*","extutil/starmatch_new","extutil/finalmatch"]
},
#'runner' is in the root.
scripts = ["addwcs"]
#long_description = """Really long text here."""
#
#This next part it for the Cheese Shop, look a little down the page.
#classifiers = []
)
------
Thanks for any help
Wolfgang