overloading setuptools provided commands (install)

[Toshio Kuratomi]

hi, I'm trying to modularise the way my application gets installed.
I'd like to install some files via a custom @task and use setuptools
install functionality for the rest. I've got the separate task coded
but what I want to do next is override the install target so that when
someone calls paver install it calls install_my_data() before calling
the setuptools install target. Is there some way to do that?

Thanks,
Toshio

[Kevin Dangoor]

@task
@needs(['install_my_data', 'setuptools.command.install'])
def install():
pass

?

--
Kevin Dangoor
Product Manager
SitePen, Inc.
Web development experts:
development, support, training

ke...@sitepen.com
http://www.sitepen.com
650.968.8787
(Timezone: US/Eastern)

[Toshio Kuratomi]

On Oct 3, 8:06 pm, Kevin Dangoor <dang...@gmail.com> wrote:
> @task
> @needs(['install_my_data', 'setuptools.command.install'])
> def install():
>      pass
>

Excellent! That's almost what I need. I have two questions about
command line options using this:

1) Is there a "best way" to get command line options that are legal
for the setuptools.command.install for use in install_my_data?

2) I'm getting this error from the setuptools.command.install portion
when I give the --root commandline option:

---> setuptools.command.install
error: error in command line: command 'build' has no such option
'root'

Any idea what's going on here?

Thanks!
-Toshio

[Toshio Kuratomi]

And the command line is:::
paver install --root `pwd`/tmp

This happens even if this is my @needs line:
@needs(['setuptools.command.install'])
def install():

-Toshio

[Kevin Dangoor]

*sigh* There's some bug in there that I haven't had a chance to look
into. This particular example is interesting, though. distutils must
have some mechanism for dealing with that, because "install" cares
about --root, but "build" does not. So, distutils must have some code
to deal with command line options that are part of one command but not
another, and Paver needs to do that as well...

Kevin

[boothead]

Hi,

I've run into this as well... I'm trying to perform a task which can
take an argument and then run develop. The develop command still seems
to get my command line option even though I've tried popping it from
the bunch, here's the code:

options(
setup=....
),
install_revision=Bunch(
revision='tip'
)
)

@task
@cmdopts([
("revision=", "r", "Revision (number or short id)")
])
def install_revision():
"""Change the working copy to a specific revision"""
rev = options.install_revision.pop('revision')
import pdb; pdb.set_trace()
try:
sh("hg up -r %s" % rev)
sh('hg revert -r tip pavement.py')
call_task("develop")
except Exception, e:
print e

This chokes if I specify the revision:

paver install_revision -r 90
---> install_revision
hg up -r 90
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
error in command line: command 'develop' has no such option 'revision'

But seems ok if not (even though there's a default one):

---> install_revision
hg up -r tip
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
---> develop
---> egg_info
writing twodsearch.egg-info/PKG-INFO
writing top-level names to twodsearch.egg-info/top_level.txt
writing dependency_links to twodsearch.egg-info/dependency_links.txt
warning: manifest_maker: standard file 'paver' not found
reading manifest file 'twodsearch.egg-info/SOURCES.txt'
writing manifest file 'twodsearch.egg-info/SOURCES.txt'
---> build_ext
Creating /home/ben/dev/virtuals/search/lib/python2.5/site-packages/
twodsearch.egg-link (link to .)
twodsearch 96-035067865bcb is already the active version in easy-
install.pth

Installed /home/ben/dev/virtuals/search/src/search
Processing dependencies for twodsearch==96-035067865bcb
Finished processing dependencies for twodsearch==96-035067865bcb

This part of the relevant pdb seems instructive:
...
/home/ben/dev/virtuals/search/lib/python2.5/site-packages/Paver-0.8.1-
py2.5.egg/paver/setuputils.py(144)run_command()
-> ns = self._current_namespace
(Pdb) s
> /home/ben/dev/virtuals/search/lib/python2.5/site-packages/Paver-0.8.1-py2.5.egg/paver/setuputils.py(146)run_command()
-> cmd_obj = self.get_command_obj(command)
(Pdb) ns
[Bunch(revision=('command line', '90'))]

At this point cmd_obj.distribution.command_options looks like:

{'aliases': Bunch(),
'easy_install': Bunch(),
'install_revision': Bunch(revision=('command line', '90'))}

Hope this is enough detail. If you can give me any pointers as to why
this happens and how to fix it, I'll be happy to take a stab at it!

Cheers,
Ben

[boothead]

Ok, I might have fixed this... Try a @consume_args... it seems to have
worked for me!

so:

@task
@cmdopts([
("revision=", "r", "Revision (number or short id)")
])

@consume_args

def install_revision():
"""Change the working copy to a specific revision"""

call_task(....)

Ben

[Kevin Dangoor]

On Oct 29, 2008, at 10:31 AM, boothead wrote:

> Ok, I might have fixed this... Try a @consume_args... it seems to have
> worked for me!

I hadn't thought of that! It's not the ideal solution, but that's a
fine workaround in many cases. Thanks!

Kevin

[Ben Ford]

Actually it ddin't work... As I've done it it consume_args kills the arguement within install_revision. I've had to do it by having two functions, moving the consume_args and the call_task into the second function and calling that from install_revision! It now looks like this:

@task
@cmdopts([
   ("revision=", "r", "Revision (number or short id)")
   ])

def install_revision():
   """Change the working copy to a specific revision"""

    # function body

   call_task('my_develop')

@task
@consume_args
def my_develop()
    call_task('develop')

I still haven't figured out where this [Bunch(revision=('command line', '90'))] is created though, and that appears to be the key to it!

Ben
  

2008/10/29 Kevin Dangoor <dan...@gmail.com>

--
Regards,
Ben Ford
ben.f...@gmail.com
+447792598685

[Kevin Dangoor]

On Oct 30, 2008, at 3:28 AM, Ben Ford wrote:

> I still haven't figured out where this [Bunch(revision=('command
> line', '90'))] is created though, and that appears to be the key to
> it!

Generally, that kind of thing is happening in paver/setuputils.py

Paver shares the command line handling duties with distutils.

Kevin

--
Kevin Dangoor

email: k...@blazingthings.com
software blog: http://www.BlueSkyOnMars.com
personal blog: http://www.kevindangoor.com