At 10:15 PM 9/21/2009 +0200, Lennart Regebro wrote:
>2009/9/21 Wolfgang Schnerring <ws(a)gocept.com>:
> > My favourite colour: use 2to3 as the prefix (consistency helps, I
> > think), like so:
> > 2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ...
>That works. Maybe just 2to3_doctests?
Really? I would think 2to3_anything is not a valid keyword argument name.
At 12:16 PM 9/16/2009 +0200, Tarek Ziadé wrote:
>On Wed, Sep 16, 2009 at 2:42 AM, <exarkun(a)twistedmatrix.com> wrote:
> > What use cases do we have? There's the one described above, which lots of
> > people have been talking about. I think there's another one related to
> > target Python version - eg, on Python 2.3, depend on simplejson, but on
> > Python 2.6, don't. What else?
>So if I resume, so far the uses cases are:
>- the OS given by os.name and sys.platform
>- the architecture, given by os.uname() (32/64 bits)
>- the python version, given sys.version_info
Do we have anything besides dependencies that change based on the
above? If not, then we might be able to address this with the
"extras" syntax mechanism already present in install_requires, and we
might able to do it without even changing that syntax.
Tarek alerted me to that Martin v Löwis has checked in the great job
done during the DZUG-sprint of adding Python 3 support to the 0.6
maintenance branch. I tested it yesterday, and I have two comments.
1. First a little heads up!!
When I tested this yesterday, I first ran the tests for various Python
versions, and then I tried to install it on Python 3.1. Unfortunately
I got a syntax error. Something was not properly converted to Python
3. Looking at the source code of the file in question showed that it
WAS converted. I thought it was the PYC-file, but then I realized you
can't get syntax-error in pyc-files. I deleted all in site-packages,
and ran the install again: Same result.
Finally I fixed it by deleting all in site-packages, and rm -rf dist
build in the distribute checkout and also deleting all pyc-files in
the distribute checkout and trying again. Since then, I have not been
able to repeat the problem. (Deleting just build and dist or just the
pyc-files or just everything in site-setup did not work. Only when I
deleted *all* of these did the problem go away).
I suspect that the existence of my setuptools port in the Python 3.1
install before running the new one made something very strange. But it
made the strangeness in either build/ or dist/. So a heads up to
everyone here: If you have used my setuptools port, make sure you
delete all traces of it from your Python 3 install *before* attempting
to install Distribute on Python 3.
2. There is now a build_py that will run 2to3 on the code. That's
cool, but there doesn't seem to be a way to enable it. It looks for a
setuptools.use_2to3 attribute to check if it should be used, but I
couldn't see a way of setting that. Passing it in as a parameter to
setup() gives you a warning, that the parameter is unknown.
How should it be done?
Lennart Regebro: Python, Zope, Plone, Grok
+33 661 58 14 64
At 01:48 PM 9/19/2009 +0100, Kyle MacFarlane wrote:
>The way setuptools (and thus buildout) does namespace packages
>doesn't work with how Django looks for management commands. Django
>only looks in the first package in the namespace on the system path
>and ignores the rest.
If they use the package's __path__ attribute, they'll find its
contents, whether someone is using pkgutil.extend_path, .pth files,
or setuptools. They don't have to support setuptools to support
namespace packages, just pay attention to the __path__ variable
that's part of standard Python.
At 09:17 AM 9/20/2009 +0100, Kyle MacFarlane wrote:
>2009/9/19 P.J. Eby <pje(a)telecommunity.com>
> > If they use the package's __path__ attribute, they'll find its
> contents, whether someone is using pkgutil.extend_path, .pth files,
> or setuptools. Â They don't have to support setuptools to support
> namespace packages, just pay attention to the __path__ variable
> that's part of standard Python.
>I was hoping more if anybody knew a recipe to get round my problem but
>I had a look inside Django to see how it looks through packages.
>The problem is caused by line 58 at this link raising an ImportError:
>It doesn't matter what order find_module is called on various paths,
>it still relies entirely on the order in sys.path. Calling find_module
>on second_app before first_app will still fail if first_app is the
>first app on sys.path (which suggests that something has been done
>wrong even before line 58 or find_module itself doesn't support
>Unfortunately I've never dealt with the imp module before. What would
>I need to do? Import the package (which is actually "path" in this
>code), get __path__ from it and then do find_module again but with
Basically, yeah, only it has to happen inside the "while parts"
loop. The downside, of course, is that you'll be importing every
application and its management package. It's too bad, really, they
could've saved a ton of code and complexity there (as well as being
able to support namespace packages, zipfiles, etc.) if they'd just
used pkg_resources and entry points. Projects could just declare
their commands without needing a management.commands subpackage, or
separate modules for each command.
Dnia czwartek 17 września 2009 o 23:07:17 A. Cavallo napisał(a):
> as rule of thumb (followed now by all major distros) you should not put any
> script in %postun, %postinst etc sections.
> > Hello,
> > I am looking for some advise in creating rpm package using bdist_rpm.
> > I have managed to create post_install part using information
> > http://stackoverflow.com/questions/1321270/how-to-extend-distutils-with-a
> >-s imple-post-install-script Now i would like to add some code to %postun
> > part of spec file to revert changes done by my post_install command.
> > Is there a way to add it in setup.py or do i have to manually edit spec
> > file?
> Distutils-SIG maillist - Distutils-SIG(a)python.org
It is not mentioned in Fedora guidelines
Ok, how would you handle creating symlink in setup.py? and removing it of
course when uninstalling rpm. That is my goal.
I managed to create symlink with setup.py but can not find any option for
removing, which is i think correct as there is no uninstall option for
The way setuptools (and thus buildout) does namespace packages doesn't work
with how Django looks for management commands. Django only looks in the
first package in the namespace on the system path and ignores the rest.
Pip deals with namespace packages differently (with those .pth files I
think), so I gave gp.recipe.pip a go but it raises an ImportError that pip
isn't installed when it tries to install pip. Nice. But even if it did work
pip doesn't support eggs which I imagine will lead to many dependencies not
Then I tried collective.recipe.omelette but it doesn't support zipped eggs
and so also fails with many dependencies. I can get round this by also using
the regular zc.recipe.egg but then I get loads of warnings about packages
being imported twice (but it all seems to kind of work).
So what is the proper way to do this? Django people are saying don't use
setuptools but everything seems to rely on setuptools.
I have a hair-brained notion of using a buildout to set up an entire
machine. Has anyone done this before? (Jim, didn't you say ZC do this a
From where I'm sitting, I'm looking for a few recipes:
- what's the best download & cmmi recipe out there?
- what's the best recipe for running other buildouts?
- is there a recipe available anywhere for installing/removing packages
Simplistix - Content Management, Batch Processing & Python Consulting