First things first: what I want to accomplish is to install pyflakes and
docutils in a buildout. That is, I want to have a bin/pyflakes and bin/rst2*
scripts.
- Buildout listens to the console_scripts entry point.
- pyflakes and docutils use the (apparently old) scripts=['scripts/pyflakes']
option instead of a console_scripts entry point.
So I have three choices:
- Ask pyflakes and docutils to use the console_scripts entry point. Is there
a reason not to use console_scripts? The "scripts=[]" comes from plain
distutils which is in the official python distribution and setuptools is
an add-on. Can this be a cause?
- Fix up buildout to also support scripts=[]. (I'm trying that one right
now).
- Write a wrapper library that depends on pyflakes/docutils and provides
proper entry points. Feels a bit dirty.
I have two questions:
- Has the console_scripts entry point superseded scripts=[]? Should it be
considered a bug in pyflakes? Or is it OK to still use it?
- How do I access that 'scripts=[....]' which is sitting right there in my
setup() call? From buildout? Buildout does something like:
req = pkg_resources.Requirement.parse('my.package')
dist = working_set.find('my.package')
dist ends up as a pkg_resources.Distribution class, which doesn't seem to
have anything with which to do "dist.scripts" or so. Anyone know the magic
call? In easy_install there's a "self.distribution.scripts", but after 4
levels of inheritance and a monkey patch I lost track where
self.distribution comes from...
Reinout
--
Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"
At 01:58 PM 9/3/2009 -0400, Jim Fulton wrote:
>I think the script information should be included somehow so that it
>can be gotten from eggs.
The original script files get stored in the "EGG-INFO/scripts" directory.
Hi o/
we recently began tu use virtualenv and buildout for development and
deployments in some projects (more one internal effort to convince the
ppl heads to use this for the next projects)
by now i have two ways to work.
1) create a venv and inside this create the buildout dir project.
2) create a venv and in the same venv directory create the buildout
tree.
by now i see that maybe the second option is little dangerous but we
dont use an custom interpreter and like we are a django shop, we use
djangorecipe and do bin/django shell (shell_plus with django_extensions)
to have a shell to the project.
by now both options require to do two operations, first create the
venv, activate this and after this create the buildout and run this.
i am thinking about develop an recipe/extension for buildout to:
- create a virtualenv
- activate the venv
- rerun the buildout using the ptyhon venv (bypassing the venv part)
my questions are:
1) someone think and do this first?
2) do you consider this alternative dangerous for some operation?
3) exist any plan for buildout to obtain the same isolation level than
virtualenv ? when ?
4) do you see any other alternative to obtain the same effect (we need
to test apps between python 2.5 and python 2.6, we see than the buildout
dont ignore the global site-package, some dev machines are really messed
in their python interpreters used and the eggs/modules/installed in
their systems, and we love to deploy the apps inside venvs with
mod_wsgi, no more hell with pythonpath)
well that's all by now ^^
--
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.com.pe
I wonder whether zc.recipe.cmmi is meant to be usable and testable in a
Windows environment. While the changelog says a Windows-related bug was
fixed last year, the tests don't succeed on the Windows box I tried today
due to file-system path handling which is being done in a non-portable and
Unix-specific way both in code and tests, and has been for a long time.
Can someone enlighten me as to what it is that I seem to have missed?
Thank you.
Viele Grüße,
Thomas
--
Thomas Lotze · tl(a)gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
With a buildout.cfg section that looks like:
[py]
recipe = zc.recipe.egg
eggs = ...
interpreter = py
If I try and do:
bin/py -m some.moldule
...I get:
Traceback (most recent call last):
File "bin/py", line 28, in <module>
_options, _args = getopt.getopt(sys.argv[1:], 'ic:')
File "/usr/local/lib/python2.6/getopt.py", line 91, in getopt
opts, args = do_shorts(opts, args[0][1:], shortopts, args[1:])
File "/usr/local/lib/python2.6/getopt.py", line 191, in do_shorts
if short_has_arg(opt, shortopts):
File "/usr/local/lib/python2.6/getopt.py", line 207, in short_has_arg
raise GetoptError('option -%s not recognized' % opt, opt)
How should whatever generates bin/py be changed to enable -m to work?
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
Hello,
is there a way to pass options to a custom distutils.core.Command from
setup.py instead of setup.cfg ? I could not find any doc about that.
Thanks !
I've made a reasonable number of recipes and there's one thing in buildout
that I want to fix. In order to fix it, I need to be able to run the tests,
of course. But the tests fail for me. Tens of them. (I've posted about this
before).
The kind of errors you get:
Expected:
setuptools.egg
- zc.buildout.egg
Got:
- setuptools.egg-link
- zc.buildout.egg
As far as I can see, there's one root cause for all of them: setuptools is
detected as a development egg on line 346 of buildout.py. There was at least
one other developer that was plagued by exact the same problem. He was on
linux, I'm on osx. So it is not specifically os-dependent.
I've tried installing setuptools (globally) in several ways. Whether I use
macport's version or the downloaded setuptools egg: no difference.
So:
- Is this a known issue?
- Is this something I really should fix in my own setup?
- Is there a known fix that can be applied to the test setup?
I'd really like to contribute :-)
Reinout
--
Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"
