At 02:58 PM 2/25/2009 +0000, Arve Knudsen wrote:
>According to WorkingSet's documentation, it should call
>find_distributions with
>False for the only-parameter.
Where in the documentation is this? It should be fixed.
>In reality, it passes True, however.
This is correct.
>The documented behaviour is what I was after,
Then you probably want an Environment, not a WorkingSet.
New submission from Arve Knudsen <arve.knudsen(a)gmail.com>:
According to WorkingSet's documentation, it should call find_distributions with
False for the only-parameter. In reality, it passes True, however. The
documented behaviour is what I was after, but maybe it could be parameterized
also in this method?
----------
keyword: pkg_resources
messages: 245
nosy: aknuds-1
priority: bug
status: unread
title: pkg_resources.WorkingSet.add_entry inconsistency
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue62>
_______________________________________________
At 01:50 AM 2/24/2009 +0100, Tarek Ziadé wrote:
>I having the same problem with the version : since it is already
>located in PKG-INFO,
>there's no need to have it in the folder name;
It's there so pkg_resources doesn't need to read the file in order to
locate an available version of the package, just the listdir() that
it was doing anyway. In other words, it's a performance
optimization, and a pretty major one when you're building an
Environment object to look for available package versions. Cuts down
on a LOT of file opens in the case where you have a ton of
.egg-info's in site-packages, like on a Linux system with Python 2.5.
Now, it is supported to leave that information out, but that's really
intended only for working with development packages/checkouts, where
you don't have so many of them on sys.path at any one time that the
extra open is a big deal.
>In Distutils, there should be one egg-info per package. (While
>setuptools multi-package
>options allows to activate/deactivate various versions of the same package).
>
>That said, I don't think this PEP should address multiple versions issues.
Note that sys.path could have more than one version of the same
package on it, in two different directories. (Granted, one would
take precedence over the other, but that should still be explicit.)
>PEP, because as far as I
>can see, the namespace package boilerplate in setuptools is using
>pkgutil.extend_path which
>fixes __path__ variables on the fly. So I can't think of a case where
>a static __init__.py file
>will be shared, thus removed.
When a distutils package does it. I'm not positive, but if 'pip'
supports namespace packages without using .pth files, then it has to
use a shared __init__ also.
And in the long run, easy_install will do this too.
So, the uninstallation code should simply not remove file(s) that are
referenced by more than one manifest in the target directory -- a
relatively simple, future-proof safeguard, that doesn't require any
specific knowledge of "namespace packages" per se.
New submission from Miroslav Madecki <miro(a)a-bb.net>:
I'm using setuptools 06c9 on CentOs 5.X i386/x86_64.
When using bdist_egg command one would expect setuptools to stop
once byte-compile encounters an error
(e.g. python source file with syntax errors) and would also return
exit value other than 0 indicating a failure.
Unfortunately neither is the case so if you use setuptools within makefiles
it won't stop make in the case of errors.
I'm surprised that nobody else reported this issue.
Example is attached below.
-Miro
[miro@t42 monty]$ python25 ipdrfc-setup.py bdist_egg
.....
byte-compiling build/bdist.linux-i686/egg/abn/ipdrfc/cfg.py to cfg.pyc
File "build/bdist.linux-i686/egg/abn/ipdrfc/cfg.py", line 184
defset_exporter(ipAddr, cfg, RexGroup=None, RexListenPort=None, LogLevel=None):
^
SyntaxError: invalid syntax
byte-compiling build/bdist.linux-i686/egg/abn/ipdrfc/reader.py to reader.pyc
byte-compiling build/bdist.linux-i686/egg/abn/ipdrfc/sshconsole.py to sshconsole.pyc
byte-compiling build/bdist.linux-i686/egg/abn/ipdrfc/backup.py to backup.pyc
creating build/bdist.linux-i686/egg/EGG-INFO
copying src/abn_ipdrfc.egg-info/PKG-INFO -> build/bdist.linux-i686/egg/EGG-INFO
copying src/abn_ipdrfc.egg-info/SOURCES.txt -> build/bdist.linux-i686/egg/EGG-INFO
copying src/abn_ipdrfc.egg-info/dependency_links.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying src/abn_ipdrfc.egg-info/namespace_packages.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying src/abn_ipdrfc.egg-info/top_level.txt -> build/bdist.linux-i686/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating 'dist/abn_ipdrfc-3.2.0-py2.5.egg' and adding
'build/bdist.linux-i686/egg' to it
removing 'build/bdist.linux-i686/egg' (and everything under it)
[miro@t42 monty]$ echo $?
0
----------
messages: 243
nosy: miro
priority: urgent
status: unread
title: bdist_egg command doesn't stop after byte-compile errors
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue61>
_______________________________________________
New submission from do3cc <do3ccqrv(a)googlemail.com>:
There is a missing dependency in the install_lib command:
http://bugs.python.org/issue5243
As a result, some eggs can not be installed. Reportlab for example
attached is a possible workaround. apply with patch -p0 < bdist_egg.diff
----------
files: bdist_egg.diff
messages: 242
nosy: do3cc
priority: wish
status: unread
title: Workaround for a distutils bug
Added file: http://bugs.python.org/setuptools/file40/bdist_egg.diff
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue60>
_______________________________________________
Hello
We have worked on a fix for bdist_rpm, to avoid the error that occurs
under Fedora or RedHat when the optimize flag is not
activated.
http://bugs.python.org/issue1533164
I am about to introduce a new option for this command, called
"force-optimize" (and activated by default)
This new option makes the bdist_rpm command drive the install command
with the "optimize" flag activated by default (this fixes the problem)
The rationale to introduce a new option is to make sure people don't
get confused between the optimize flag that is forced when building a
rpm package,
and the "regular" optimize option used by the install command.
This will prevent undesired side-effects. For instance, writing a
setup.cfg with "optimize" to build rpms, might interfer when someone
tries to
tries to install the same package under Jython,
Any opinion ? Otherwise I'll commit it this way
Regards
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
At 04:50 AM 2/22/2009 +0100, Tarek Ziadé wrote:
>On Sun, Feb 22, 2009 at 4:30 AM, P.J. Eby <pje(a)telecommunity.com> wrote:
> > At 11:55 PM 2/21/2009 +0100, Tarek Ziadé wrote:
> >>
> >> Hi Phillip,
> >>
> >> Some changes in distutils/sdist are breaking some commands in
> >> setuptools' egg_info because of a getattr that make a recursive error,
> >>
> >> I think it could be a great thing to fix it as soon as possible before
> >> Python 2.6.1 is out,
>
>Typo : before the first version of 2.7 is out
>
>Notice that standalone releases of Distutils are planned soon, including a
>development snapshots, so it should be easier to test the latest changes.
>
> >>
> >> I am available if you need more info on this
> >
> > At a bare minimum, the Python SVN revision numbers and the resulting
> > traceback would be helpful. A bug filed to the setuptools tracker would
> > probably also be a good idea, so that I'm not the only person who can look
> > at it or provide a fix... either for setuptools or the stdlib, as
> > appropriate.
> >
>
>Sure,
>
>it happens because setuptools build_py implementation has a __getattr__ that
>computes data_file::
>
> def __getattr__(self,attr):
> if attr=='data_files': # lazily compute data files
> self.data_files = files = self._get_data_files(); return files
> return _build_py.__getattr__(self,attr)
>
>But Distutils sdist command loops over build_py.data_files to add them
>in the MANIFEST file,
>because this attribute should be computed by finalize_command.
>
>And this is done when sdist.add_default is called, so it loops
>recursively and dies
>
>see "for pkg, src_dir, build_dir, filenames in build_py.data_files: in"
>
>http://svn.python.org/view/python/trunk/Lib/distutils/command/sdist.py?r1=6…
I'm not sure this problem is fixable on the setuptools side -- the
calculation was made lazy specifically to *avoid* this problem! That
is, I intentionally prevented Python 2.4+ distutils from calculating
the data files during option finalization, because the data files
can't be correctly known until *after* the manifest is built.
I have no idea what to do about this -- on either setuptools or
distutils. For setuptools, file list calculation is inherently
circular - an existing manifest is always reused and pruned, in order
to support situations where a revctrl-based file list is then used in
a scenario without revision control. (That is, the MANIFEST included
with a shipped sdist is used as a backup for identifying files that
might originally have been found via a revctrl finder.)
At 11:55 PM 2/21/2009 +0100, Tarek Ziadé wrote:
>Hi Phillip,
>
>Some changes in distutils/sdist are breaking some commands in
>setuptools' egg_info because of a getattr that make a recursive error,
>
>I think it could be a great thing to fix it as soon as possible before
>Python 2.6.1 is out,
>
>I am available if you need more info on this
At a bare minimum, the Python SVN revision numbers and the resulting
traceback would be helpful. A bug filed to the setuptools tracker
would probably also be a good idea, so that I'm not the only person
who can look at it or provide a fix... either for setuptools or the
stdlib, as appropriate.
Hi,
The API reference for distutils tells how to get an instance of a new
compiler sub-class with the following command:
mycompiler = distutils.ccompiler.new_compiler(*plat=None*, *compiler=None*,
*verbose=0*, *dry_run=0*, *force=0*)
The API also specifies the commands to modify specific parameters within the
returned compiler sub-class. However the API says nothing about how to
actually "use" the new sub-class. In other words, how does one go about
getting the following to work (or something similar)?
python setup.py build
where the build steps now use 'mycompiler'
Thanks,
-Simon
