On Wed, Sep 2, 2009 at 9:07 AM, Reinout van Rees<rein...@vanrees.org> wrote:
> 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?
Perhaps.
Note that, as Tarek reminded us, buildout lets you define entry points
yourself. In fact, I happen to have done this for pyflakes myself a
couple of weeks ago:
[pyflakes]
recipe = zc.recipe.egg
eggs = pyflakes
entry-points = pyflakes=pyflakes.scripts.pyflakes:main
> - Fix up buildout to also support scripts=[]. (I'm trying that one right
> now).
For a long time, I maintained that this wasn't practical. I do think
90% (maybe a 100%) solution of possible. It will require generating
scripts that set up the path and then include the source of the
original scripts. This is rather ugly but probably doable. Of
course, there's also the pain that the script meta data isn't
available cleanly, as you point out below.
>
> - 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?
I personally think entry points are cleaner, but I think it would be
rather bold to call use of scripts a bug. :)
> - 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...
Yeah, it's too bad that the meta data is lost. It amazes me how
willing distutils and setuptools are to toss meta data passed to
setup.
You could probably invoke the install command telling it to install
the scripts in some place and then grab them, but that sounds nasty
too.
Jim
--
Jim Fulton
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
