I've been trying to build rpms of enthought system components. Some of
them use namespace packages. Those packages have the required __init__.py
files containing
"__import__('pkg_resources').declare_namespace(__name__)".
According to the Setuptools Guide, these __init__.py files are not to be
packaged when using "system" packaging (such as bdist_rpm) and when I run
bdist_rpm they are not included in the rpms. However, there are egg-info
directories and nspkg.pth files produced, included in the rpms, and
installed in site-packages. When I tried to run the enthought example
applications, I had various kinds of import failures. I found that fixing
them required putting the unpackaged __init__.py files into the relevant
directories in the namespace packages.
The various rpms were being placed in the proper locations where they
should have been found for importing. There were some strange errors,
such as in one case when I tried to test the imports interactively an
"import a.b.c" worked, but an "import a.b.c as c" failed.
Before putting in the __init__.py files, I tried removing the egg-info and
nspkg.pth files from site_packages. That did not improve things. I also
noticed that some other packages had pth files in site-packages, so that
may be what is needed if the egg-info and nspkg.pth are removed, although
I don't know why or what the pth files are supposed to contain.
I think setuptools is somehow not properly processing bdist_rpm if there
are namespace packages involved. Also, the setuptools don't seem to have
an option to not create the egg info and nspkg.pth files and/or to not
package them if bdist_rpm is being used.
Stan Klein
At 12:56 AM 7/23/2007 -0400, Fred Drake wrote:
>On 7/22/07, Phillip J. Eby <pje(a)telecommunity.com> wrote:
>>Setuptools has lots of features that are targeted at different
>>audiences. There are plenty of features targeted at the group you're
>>in, don't begrudge the other groups their features. :)
>
>Actually, I suspect this is a substantial contributor to setuptools
>being considered controversial: it encompasses to many different
>features.
That's precisely my point, though: "too many" always means "has
features I don't use", even though the features one person uses are
considered superfluous by other parties, who consider the first
person's "superfluous" features essential.
However, I'm entirely reconciled to it being controversial. It is in
fact impossible to have a significant impact on *anything* without
creating controversy, as anyone involved with the history of Zope
should be well aware. ;-)
Usually, people think they can get away with making "simpler"
versions of Zope because they don't understand the full range of
requirements which it is intended to meet. The situation with
setuptools is much the same, except that sometimes now it's the Zope
folks making the accusations of too many features, excess complexity,
evil, etc. :)
(I normally work from Linux, but have a test WinXP computer and my old
WinNT4 with Visual Studio 6 should that turn out to be useful.)
It is quite easy to use the bdist_wininst command to create a Windows
installer executable. A browser click on a link to the .EXE file allows
for software installation, but easy_install is not run and the packages
listed in setup.install_requires are not installed. Is there a way to
force the windows installer to run easy_install?
If I were to create an egg, is there a content-type heading that would
cause easy_install to process the egg?
(much like application/vnd.ms-excel)
I could not find an easy_install entry in the registry in my test WinXP
computer after installing setuptools.
I thought one of these approaches would be fairly easy, but googling and
experimenting have gotten me nowhere.
--
Lloyd Kvam
Venix Corp
Hello,
We need to make an executable installer for MS Windows, we guess using
bdist_wininst.
The installer should package in one single installation on python 2.5
PIL, docutils and itools.
We should rather not compile PIL on windows (it's big) but use perhaps the binary distribution
for windows: http://effbot.org/downloads/PIL-1.1.6.win32-py2.5.exe
Thank's
--
Sylvain
At 07:23 PM 8/7/2007 -0600, Jeff Shell wrote:
>So we've never done much with eggs or distutils up until now at my
>company. We've generally worked in Zope. We generally check out Python
>packages directly into a directory where Zope would automatically pick
>them up. So we've never gotten into any convention of having a layout
>that I commonly see these days:
>
> distroot
> - setup.py
> + src
> + ourlib
> - __init__.py
> - etc...
>
>Fearing that we'd have to dramatically change our source code around,
>and shake up existing checkouts, I've avoided trying to add any
>distutils/setuptools support to these packages. But I was told
>recently that I could have `setup.py` in the package root (`ourlib` in
>the example above).
You can, but putting it one level higher (e.g. 'src') would be much
better. Putting it inside the package means you can't get the
"develop" or "test" commands to work correctly... as you mention below.
> I've seen this work in a plain distutils system
>(Chris McDonough's BuildIt), but I've had a nightmare of a time
>getting it to work with setuptools and zc.buildout and on and on.
>
>Some code lies below that tries to explain the dilemma and shows my
>best guess efforts so far. Has anyone had any success with this
>layout?
>
>I was trying to use this as a 'develop' egg(?) using `zc.buildout`,
>and it doesn't work. In a generated 'virtual-python' kind of thing, it
>sets up this in sys.path (when specifying ``develop=src/ourlib`` in
>`buildout.cfg`):
>
> sys.path[0:0] = [
> '/Users/jshell/Documents/Programming/eggify/src/fdlib',
> ...
>
>This seems like an uphill battle. Any tips?
"develop" won't work unless your project directory contains packages;
i.e., setup.py has to be in "src" for this to work. That's because
some directory needs to get put in sys.path, that has both the
.egg-info/ dir and the actual packages as subdirectories.
So we've never done much with eggs or distutils up until now at my
company. We've generally worked in Zope. We generally check out Python
packages directly into a directory where Zope would automatically pick
them up. So we've never gotten into any convention of having a layout
that I commonly see these days:
distroot
- setup.py
+ src
+ ourlib
- __init__.py
- etc...
Fearing that we'd have to dramatically change our source code around,
and shake up existing checkouts, I've avoided trying to add any
distutils/setuptools support to these packages. But I was told
recently that I could have `setup.py` in the package root (`ourlib` in
the example above). I've seen this work in a plain distutils system
(Chris McDonough's BuildIt), but I've had a nightmare of a time
getting it to work with setuptools and zc.buildout and on and on.
Some code lies below that tries to explain the dilemma and shows my
best guess efforts so far. Has anyone had any success with this
layout?
I was trying to use this as a 'develop' egg(?) using `zc.buildout`,
and it doesn't work. In a generated 'virtual-python' kind of thing, it
sets up this in sys.path (when specifying ``develop=src/ourlib`` in
`buildout.cfg`):
sys.path[0:0] = [
'/Users/jshell/Documents/Programming/eggify/src/fdlib',
...
This seems like an uphill battle. Any tips? My fallback plan is to
have a separate 'releases' area of our repository which houses
setup.py and such for each of these packages along with a script to
check out the main source before building an distribution or using as
a develop-egg-thing.
Is there anything, specific to this problem, that I can be doing
better with this setup.py?
from setuptools import setup, find_packages
def list_packages():
packages = [
'ourlib.%s' % subpackage
for subpackage in find_packages()
]
packages.insert(0, 'ourlib')
return packages
setup(
name = 'ourlib',
version = "1.0a1",
packages = list_packages(),
package_dir = {'ourlib': '.'},
include_package_data = True,
install_requires=['setuptools'],
extras_require = dict(
test = ['zope.testing'],
),
zip_safe = False,
)
Without that 'list_packages', the results of `find_packages` would
return 'toolkit' instead of 'ourlib.toolkit': the package head that
would normally be there is off.
Thanks,
Jeff Shell
Hello,
I was download egg file bbfreeze-0.95.2-py2.4-win32.egg ( for windows
of course ),and I have setuptools
version 0.6c6 after I try install this with setuptools:
$ ez_setup bbfreeze-0.95.2-py2.4-win32.egg
Traceback (most recent call last):
File "C:\Python24\Lib\site-packages\ez_setup.py", line 226, in ?
main(sys.argv[1:])
File "C:\Python24\Lib\site-packages\ez_setup.py", line 183, in main
from setuptools.command.easy_install import main
File "C:\Python24\Lib\site-packages\setuptools\command
\easy_install.py", line 16, in ?
from distutils import log,dir_util
ImportError: cannot import name log
Regards,
Vedran
__________________________________________________________________
Vedran veki
ICQ#: 264412055
Current ICQ status:
+ More ways to contact me
Get ICQ!
__________________________________________________________________
Robert Kern wrote:
Stanley A. Klein wrote:
>> I tried to do something to fix the numpy distutils bdist_rpm.py (by
>> trying to follow what was done in install.py) but it didn't work and I
>> got an error message I didn't understand.
>I'd like to help, but if you don't copy the exact error message here, I
can't.
OK, here is my revised numpy/distutils/commands/bdist_rpm.py (trying --
obviously not well -- to follow what was done in
numpy/distutils/commands/install.py:
import os
import sys
if 'setuptools' in sys.modules:
import setuptools.command.bdist_rpm as old_bdist_rpm
class bdist_rpm(old_bdist_rpm):
pass
else:
from distutils.command.bdist_rpm import bdist_rpm as old_bdist_rpm
class bdist_rpm(old_bdist_rpm):
def _make_spec_file(self):
spec_file = old_bdist_rpm._make_spec_file(self)
# Replace hardcoded setup.py script name
# with the real setup script name.
setup_py = os.path.basename(sys.argv[0])
if setup_py == 'setup.py':
return spec_file
new_spec_file = []
for line in spec_file:
line = line.replace('setup.py',setup_py)
new_spec_file.append(line)
return new_spec_file
And here is the error message I got (using the kiva setup.py):
[stan@localhost enthought.kiva_2.0]$ python setup.py bdist_rpm
Traceback (most recent call last):
File "setup.py", line 2, in ?
from numpy.distutils.core import setup
File "/usr/lib/python2.4/site-packages/numpy/distutils/core.py", line
32, in ? from numpy.distutils.command import bdist_rpm
File
"/usr/lib/python2.4/site-packages/numpy/distutils/command/bdist_rpm.py",
line 6, in ?
class bdist_rpm(old_bdist_rpm):
TypeError: Error when calling the metaclass bases
module.__init__() takes at most 2 arguments (3 given)
BTW, below is what the unpackaged files error looks like (with a traceback
generated by having the DISTUTILS_DEBUG environment variable set). In a
much earlier thread I learned that this can usually be resolved by setting
[install] optimize=1 in setup.cfg.
---------------------------------------------------------------------------
Installed (but unpackaged) file(s) found:
/usr/lib/python2.4/site-packages/enthought/__init__.pyc
/usr/lib/python2.4/site-packages/enthought/__init__.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/benchmark.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/benchmark.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/conv.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/conv.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/dash.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/dash.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion_data.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion_data.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/polygon_hit_test.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/polygon_hit_test.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/rect.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/rect.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple2.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple2.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple_clip.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple_clip.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star1.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star1.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star2.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star2.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star_path.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star_path.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/sub_path.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/sub_path.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/text_ex.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/text_ex.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/tk_ex.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/tk_ex.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_brain.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_brain.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_demo.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_demo.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_image_copy.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_image_copy.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lines.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lines.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lion.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lion.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/affine_matrix_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/affine_matrix_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/clip_to_rect_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/clip_to_rect_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/compiled_path_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/compiled_path_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/gcmemtest.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/gcmemtest.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/graphics_context_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/graphics_context_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/image_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/image_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/join_stroke_path_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/join_stroke_path_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/points_in_polygon_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/points_in_polygon_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/rgba_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/rgba_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/stroke_path_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/stroke_path_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_arc.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_arc.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_draw_dash.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_draw_dash.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_ft.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_ft.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_graphics_context_system.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_graphics_context_system.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_image3.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_image3.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_save.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_save.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_utils.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_utils.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/unicode_font_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/unicode_font_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/tests/affine_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/tests/affine_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/tests/basecore2d_test_case.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/tests/basecore2d_test_case.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/tests/mac_simpletest.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/tests/mac_simpletest.pyo
/usr/lib/python2.4/site-packages/enthought/kiva/tests/macport_test.pyc
/usr/lib/python2.4/site-packages/enthought/kiva/tests/macport_test.pyo
Traceback (most recent call last):
File "setup.py", line 108, in ?
version = '2.0b1',
File "/usr/lib/python2.4/site-packages/numpy/distutils/core.py", line
174, in setup
return old_setup(**new_attr)
File "/usr/lib/python2.4/distutils/core.py", line 149, in setup
dist.run_commands()
File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
cmd_obj.run()
File "/usr/lib/python2.4/distutils/command/bdist_rpm.py", line 365, in run
self.spawn(rpm_cmd)
File "/usr/lib/python2.4/distutils/cmd.py", line 398, in spawn
spawn(cmd, search_path, dry_run= self.dry_run)
File "/usr/lib/python2.4/distutils/spawn.py", line 37, in spawn
_spawn_posix(cmd, search_path, dry_run=dry_run)
File "/usr/lib/python2.4/distutils/spawn.py", line 165, in _spawn_posix
raise DistutilsExecError, \
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit
status 1
At 11:31 AM 8/6/2007 -0600, Jeff Shell wrote:
>On 8/6/07, Phillip J. Eby <pje(a)telecommunity.com> wrote:
> > At 07:57 AM 8/6/2007 -0600, Jeff Shell wrote:
> > >A basic fix appears to be easy: add another `re_finder` for
> > >`CVS/Entries.Log` with a regex like ``^A\s\w?/([^/]+)/``.
> >
> > I'd add this, but since I don't have data to test it on and you
> > apparently do, please send a tested patch and I'll add it to the
> next version.
>
>By "tested patch", do you want a unit test to accompany the patch? Or
>do you just want it to have been tested by me and compared against the
>current release?
The latter.
>In any case, I think I have such a patch. Where to send?
Me, the list, or both. :)
At 07:57 AM 8/6/2007 -0600, Jeff Shell wrote:
>A basic fix appears to be easy: add another `re_finder` for
>`CVS/Entries.Log` with a regex like ``^A\s\w?/([^/]+)/``.
I'd add this, but since I don't have data to test it on and you
apparently do, please send a tested patch and I'll add it to the next version.
>I'm sure I
>could add something like this with an entry-point and our own egg, but
>it seems ridiculously small for us to maintain internally.
Of course; it should be in setuptools. It's just been years since
I've used CVS, and I've never encountered this issue.
