paver / paver Goto Github PK

View Code? Open in Web Editor NEW

457.0 13.0 85.0 1.78 MB

Python-based project scripting.

Home Page: https://pythonhosted.org/Paver

License: Other

Python 97.40% PowerShell 1.76% Batchfile 0.54% Shell 0.03% Dockerfile 0.26%

paver's Introduction

Paver - Easy Scripting for Software Projects

Web: https://pythonhosted.org/Paver/
Download: https://pypi.python.org/pypi/Paver/
Source: https://github.com/paver/paver/
Keywords: build, scripting, make alternative, svn, git, path.py, documentation, automation, tasks, virtualenv, integration

Paver is a Python-based software project scripting tool along the lines of Make or Rake. It is not designed to handle the dependency tracking requirements of, for example, a C program. It is designed to help out with all of your other repetitive tasks (run documentation generators, moving files about, downloading things), all with the convenience of Python’s syntax and massive library of code.

Documentation

Current build status:

Documentation is hosted on PyPI (docs for development version are on GitHub).

Installation

You can install Paver either via the Python Package Index (PyPI) or from source.

To install a PyPI release using `pip`:

$ pip install -U Paver

… or alternatively from source (github master):

$ pip install -e git+https://github.com/paver/paver.git#egg=Paver

To install using `easy_install`:

$ easy_install -U Paver

Testing

Reference test suite can be run using Docker:

sudo docker run -it paver/paver

When developing locally, build it first:

sudo docker build -t  paver/paver . && sudo docker run -it paver/paver

When trying to debug inside the dev environment, run:

sudo docker run -it paver/paver /bin/bash

Alternatively, on your unix computer without any virtualization to catch environment-specific bugs:

$ virtualenv paver-venv
$ source paver-venv/bin/activate
(paver-venv) $ pip install -r test-requirements.txt
(paver-venv) $ python setup.py test

The equivalent on your windows computer over the command promt:

> virtualenv paver-venv
> paver-venv\Scripts\activate
(paver-venv) > pip install -r test-requirements.txt
(paver-venv) > python setup.py test

Getting Help

Mailing list

For any discussion about usage or development of Paver, you are welcomed to join the paver mailing list .

IRC

Come chat with us on IRC. The #paver channel is located at the Freenode network.

Bug tracker

If you have any suggestions, bug reports or annoyances please report them to GitHub issue tracker.

paver's People

Contributors

Stargazers

Watchers

paver's Issues

Allow task decorator to take virtualenv argument

Suggestion by donovan;

The ideal solution would be to be able to specify an environment in
the @task decorator

no_auto tasks will still call the auto task

(from http://code.google.com/p/paver/issues/detail?id=57 by F.Ingram.lists)

Reported by [email protected], Aug 20, 2010
What steps will reproduce the problem?

Define a task as no_auto
Run the task
The auto task will run after the specified task

What is the expected output? What do you see instead?

Expect to not see the auto task at all.

What version of the product are you using? On what operating system?

1.0.3 on Windows.

Please provide any additional information below.

The problem seems to be in the no_auto checking logic in _process_commands in tasks.py.

{{{
def _process_commands(args, auto_pending=False):
first_loop = True
while True:
task, args = _parse_command_line(args)
if auto_pending:
if not task or not task.no_auto:
environment.call_task('auto')
auto_pending=False
if task is None:
if first_loop:
task = environment.get_task('default')
if not task:
break
else:
break
task()
first_loop = False
}}}

The first time through the loop will act correctly. The task will be defined and will have no_auto set so the following check will fail:

        if not task or not task.no_auto:
            environment.call_task('auto')

This evaluates as (False or False) == False. The second time through the loop, however, the task will not be defined and so the check will evaluate as (True or AttributeError) == True.

I've changed my local copy to read:

        if task and not task.no_auto:
            environment.call_task('auto')

And this seems to produce the correct behaviour. Apologies for the lack of patch or tests.

Bundle pip as part of minilib

v 1.0.3: Cannot install with python-2.{4,5} using --no-compile option

There are error when executing the following command in Paver-1.0.3/ sources directory:

$ python2.5 setup.py install --no-compile
running install
Traceback (most recent call last):
  File "setup.py", line 7, in 
    paver.tasks.main()
  File "paver-minilib.zip/paver/tasks.py", line 621, in main
  File "paver-minilib.zip/paver/tasks.py", line 604, in _launch_pavement
  File "paver-minilib.zip/paver/tasks.py", line 569, in _process_commands
  File "paver-minilib.zip/paver/setuputils.py", line 146, in __call__
  File "/usr/lib/python2.5/distutils/dist.py", line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 879, in get_command_obj
    self._set_command_options(cmd_obj, options)
  File "/usr/lib/python2.5/distutils/dist.py", line 919, in _set_command_options
    % (source, command_name, option))
distutils.errors.DistutilsOptionError: error in command line: command 'install' has no such option 'no_compile'

Same for python-2.4 and with 2.6 it works fine.
With distutils-based packages this option (--no-compile) works fine.
Distributions tested: Gentoo, Ubuntu 10.10

This option is used in Gentoo script (ebuild) for building/installing Paver.

Use minilib only if full paver is not available

Eventual duplicate import leads to variety of warnings and other nasty things.

remove code for obsolete versions of python

There are some conditions in code which try to handle python < 2.3. This code is obsolete, due to massive use of decorators, that were added in python 2.4. Thus this code can be removed.

paver.virtual.bootstrap issues

Hello,

When trying to use paver.virtual.bootstrap from version 1.1.0, I get this error:

  File "/usr/local/lib/python2.6/dist-packages/Paver-1.0.5-py2.6.egg/paver/virtual.py", line 53, in _create_bootstrap
    bootstrap_contents = virtualenv.create_bootstrap_script(extra_text)
AttributeError: 'function' object has no attribute 'create_bootstrap_script'

It seems that the virtualenv decorator is clashing with the virtualenv import in that file. So I have renamed the decorator to get around that.

Also, when trying to run paver.virtual.bootstrap, it attempts to install paver version 1.1.0 which is not reachable using easy_install. The highest version easy_install can find is 1.0.5. This is the output:

paver bootstrap
---> pavement.bootstrap
---> paver.virtual.bootstrap
Write bootstrap script test/bootstrap.py
cd test; /usr/bin/python2.6 bootstrap.py
New python executable in ./bin/python2.6
Also creating executable in ./bin/python
Installing setuptools............done.
Installing pip...............done.
Searching for paver==1.1.0
Reading http://pypi.python.org/simple/paver/
Reading http://www.blueskyonmars.com/projects/paver/
Reading http://paver.github.com/
No local packages or download links found for paver==1.1.0

Is there something that I am doing wrong? I would like to keep using version 1.1.0 as the virtualenv decorator is very useful.

Thank you!

Add proper classifiers to setup

Jumbled output when writing to a pipe

Given task a:

from paver.easy import task, sh

@task
def a():
    sh('ls /')

running paver a is fine but running paver a | cat produces:

bin
boot
dev
etc
home
lib
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
---> pavement.a
ls /

paver -h doesn't work unless you import *

If you have an empty pavement.py, and run paver -h, you get:

Build failed: Unknown task: help

If you have a task called help in your pavement.py, it gets executed instead of paver's help:

from paver.easy import *

@task
def help(): print "nope"

yields:

$ paver -h
---> pavement.help
nope

paver -h should not depend on any import, or on anything in the pavement.py, it should be handled directly by the paver program.

I base this opinion on the fact that a failing paver -h (and paver --help) was an extreme source of confusion for me in attempting to learn how to use paver.

docs are not built on readthedocs properly

Option support causes some regressions

i.e. when using tuple and shortname is None.

Also, no tests & no doc.

related to #41

/usr/bin/paver has hard coded python path

Reported by [email protected], Apr 20, 2009 (chris.burroughs) at http://code.google.com/p/paver/issues/detail?id=32
What steps will reproduce the problem?

 $ head -n 2 /usr/bin/paver
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'Paver==1.0','console_scripts','paver'

What is the expected output? What do you see instead?

Should use 'env python'

What version of the product are you using? On what operating system?
$ uname -a
Linux chris-laptop 2.6.27-11-generic #1 SMP Wed Apr 1 20:57:48 UTC 2009
i686 GNU/Linux

Please provide any additional information below.

I presume this has something to do with entry_point in paver's own
pavement.py but I was unable to determine how the the setuptools magic worked.

Cannot run unit tests in fresh clone

I try to run the unit tests with paver test and 5 tests are failing due to import errors.

What is the proper command/configuration to run the tests?

virtual.py bootstrap not indented

Hello,

The code at https://github.com/paver/paver/blob/master/paver/virtual.py#L33 used to be indented. It's now causing this error:

---> paver.virtual.bootstrap
Write bootstrap script test/bootstrap.py
cd test; /usr/bin/python2.6 bootstrap.py
  File "bootstrap.py", line 1765
    args[:] = ['.']
       ^
IndentationError: expected an indented block

How to avoid minilib.zip

There are some problems with minilib.zip:
#45, #46, #49, no python3 support,..

I'm not sure why minilib.zip is recommended by the documentation.
Most of the projects don't need anything from minilib.zip for the install task.
The only feature I use is that project info is not duplicated.
But this can be achived in other ways. For example:
I have a standard setup.py in https://github.com/ponty/EasyProcess and
I read it from pavement.py by this hack:

# get info from setup.py
setup_py=''.join([x for x in path('setup.py').lines() if 'setuptools' not in x])
exec(setup_py)

Now the package can be installed under Python3 and paver is used only for development under Python 2.7.
This hack doesn't help projects with custom install process of course.

Maybe someone can find a better solution to avoid minilib.zip

Task for rebuilding paver.github.com

paver.github.com should always contains newest documentation from trunk and point to http://packages.python.org/Paver/ for latest stable.

error in virtualenv example

I tried to run the virtualenv example:

https://github.com/paver/paver/blob/master/docs/source/virtualenv.rst

from paver.easy import task
from paver.virtual import virtualenv

@task
@virtualenv(dir="virtualenv")
    def t1():
        import some_module_existing_only_in_virtualenv

First I got IndentationError, I fixed it, then I got: TypeError: 'module' object is not callable

Paver 1.0.5

Python 2.6.6

Be able to call_task with arguments

Sometimes it is handy to do "conditional reverse needs".

For the first stage, allow call_task with args/options as an argument.

Ability to specify shared options

As requested in https://groups.google.com/d/topic/paver/RymyiqdaN1A/discussion

Implement an argument for task to specify tasks that it can share arguments with:

@cmdopts([opt], share_with=[task1, …])

Warnings with bootstrap

No local packages or download links found for paver==1.0.4
Best match: None
Traceback (most recent call last):
File "virtualenv/bin/easy_install", line 8, in
load_entry_point('setuptools==0.6c11', 'console_scripts', 'easy_install')()
File "/home/lukas.linhart/projects/paver/virtualenv/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 1712, in main

  File "/home/lukas.linhart/projects/paver/virtualenv/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 1700, in with_ei_usage

  File "/home/lukas.linhart/projects/paver/virtualenv/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 1716, in <lambda>

  File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
  File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
  File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
  File "/home/lukas.linhart/projects/paver/virtualenv/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 211, in run

  File "/home/lukas.linhart/projects/paver/virtualenv/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 434, in easy_install

  File "/home/lukas.linhart/projects/paver/virtualenv/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/package_index.py", line 475, in fetch_distribution
AttributeError: 'NoneType' object has no attribute 'clone'

Add --traceback option

When traceback is enabled, PavementErrors are not hidden, but propagated further.

easy_install fails with conflicting paver-minilib.zip files

If paver-minilib.zip is generated for different dependant packages with different paver version
then easy_install can fail.
Example: ponty/PyVirtualDisplay#5

Possible workarounds:

using pip instead easy_install
calling easy_install more times: first fails, second succeeds
uploading all package with latest paver-minilib.zip

Paver-minilib.zip changing by each sdist

Paver-minilib.zip file content is changing by each sdist task call, because the file modification time is always updated
in the PKZip header. There was no such behavior in previous versions.
I use git and I don't know if file change is important or just time update.

Version: Paver 1.0.5

Task discovery

Write basic API for discovering task by introspection & wrapping from other projects/libraries.

Run Paver on Travis CI

Play nice with py2exe

It would be nice if paver would play nice with py2exe. I am using the last release but have run into: http://groups.google.com/group/paver/browse_thread/thread/5eb90f12298edc5a/1e14403b32152f42

Cheers
Dirk

Provide a way to hide auxilary tasks

Provide @no_help decorator that will cause task being hidden from paver help.

For discussion, see http://groups.google.com/group/paver/browse_thread/thread/ac3217c61f65b2a4

paver ignores install_requires in setup.py

Issue is already described over here:
https://code.google.com/p/paver/issues/detail?id=42

it's caused by this conditional in setuptools.command.install: ~70

if caller_module != 'distutils.dist' or caller_name!='run_commands':
    # We weren't called from the command line or setup(), so we
    # should run in backward-compatibility mode to support bdist_*
    # commands.
    _install.run(self)
else:
    self.do_egg_install()

...so when setup.py is dispatched by paver, it uses install() from distribute (if branch), which doesn't process requirements

"solved" by this hack:
https://github.com/yedpodtrzitko/paver/commit/7fe05f04195b6b4af1bf963e792fdf63a4963624

Add a way to wrap another task

For example, when wrapping distutils task (like build), one does not want to cut&paste all the possible options. Thus, provide @wraps decorator that would take same options/args as wrapped task.

generated sdist crashes with easy_install

How to replicate:

create virtualenv
bin/easy_install http://download.flexget.com/unstable/FlexGet-1.0r1424.tar.gz

It will fail because easy_install will essentially run setup.py bdist_egg after extracting tar.gz and this seems to be same as bdist_egg task in pavement to my surprise.

In that task it will try to do something that does not work correctly in tar.gz context.

Workaround I applied few months ago:

http://flexget.com/changeset?reponame=&old=1533%40trunk%2Fpavement.py&new=1531%40trunk%2Fpavement.py

I think the reason was minilib task, which was not even needed at that time.

Anyway, would be nice to get a proper fix for this. I can test if needed ...

path.py rename

Hi, when using rename, it tries to do it twice:
https://github.com/paver/paver/blob/master/paver/path.py#L902

Need a way to call a task repeatedly

Reported by [email protected], Mar 25, 2009 (by a.badger) on http://code.google.com/p/paver/issues/detail?id=25

What steps will reproduce the problem?

Add the following task:

@task
def test():
for locale in ('en', 'es'):
dry('paver compile_catalog -D test -d test'
' -i %(locale)s.po --locale %(locale)s' %
{'locale': locale},
call_task, 'babel.messages.frontend.compile_catalog')

copy a .po file to en.po and es.po
run paver test

What is the expected output? What do you see instead?
I expect to get two test.mo files in test/es/LC_MESSAGES/test.mo and
test/en/LC_MESSAGES/test.mo

Instead, only one file is created.

What version of the product are you using? On what operating system?
paver-1.0
Fedora 10

Please provide any additional information below.
It appears that the compile_catalog is only called once. We need a way to
call the task repeatedly rather than just once.

Setuptools causes weird conflicts with task discovery

If i do paver somethingnot.setuptools.like.install it tries to run the setuptools install task no matter what.

If i define my tasks before setuptools, it then works fine.

(My workaround was to create a new task finder that is installed before running setup())

Allow fabric API usage inside paver tasks

See http://groups.google.com/group/paver/browse_thread/thread/6800bcf91044aceb?hl=en and http://aurelianito.blogspot.com/2011/06/integracion-paver-fabric.html , also look at #10 and #14

Allow minilib to include other arbitrary libs

http://code.google.com/p/paver/issues/detail?id=48

Allow specifying options sharing against dependency chain

As an extension to #7, allow this test case:

def test_options_may_overlap_between_multiple_tasks_even_when_specified_in_reverse_order():
    @tasks.task
    @tasks.cmdopts([('foo=', 'f', "Foo!")], share_with=['t2', 't3'])
    def t1(options):
    assert options.t1.foo == "1"

    @tasks.task
    @tasks.needs('t1')
    @tasks.cmdopts([('foo=', 'f', "Foo!")])
    def t2(options):
    assert options.t2.foo == "1"

    @tasks.task
    @tasks.needs('t1')
    @tasks.cmdopts([('foo=', 'f', "Foo!")])
    def t3(options):
    assert options.t3.foo == "1"

    environment = _set_environment(t1=t1, t2=t2, t3=t3)

    tasks._process_commands("t2 -f 1".split())

    assert t1.called
    assert t2.called

    tasks._process_commands("t3 -f 1".split())

    assert t1.called
    assert t3.called

Python 2.5 is broken

py2.5 support is broken according to travis.

Either mark it as unsupported in docs, or fix it.

Possible bug in 1.0.4

This was asked by iwillig on IRC (when I was not around, from http://paste.pocoo.org/show/323975/)

Traceback (most recent call last):
  File "/home/ivan/dev/python/geoenv/bin/paver", line 9, in <module>
load_entry_point('Paver==1.0.4', 'console_scripts', 'paver')()
  File "/home/ivan/dev/python/geoenv/lib/python2.6/site-packages/Paver-1.0.4-py2.6.egg/paver/tasks.py", line 643, in main
_launch_pavement(args)
  File "/home/ivan/dev/python/geoenv/lib/python2.6/site-packages/Paver-1.0.4-py2.6.egg/paver/tasks.py", line 626, in _launch_pavement
_process_commands(args, auto_pending=auto_pending)
  File "/home/ivan/dev/python/geoenv/lib/python2.6/site-packages/Paver-1.0.4-py2.6.egg/paver/tasks.py", line 579, in _process_commands
task, args = _parse_command_line(args)
  File "/home/ivan/dev/python/geoenv/lib/python2.6/site-packages/Paver-1.0.4-py2.6.egg/paver/tasks.py", line 518, in _parse_command_line
args = task.parse_args(args)
  File "/home/ivan/dev/python/geoenv/lib/python2.6/site-packages/Paver-1.0.4-py2.6.egg/paver/tasks.py", line 320, in parse_args
parser = self.parser
  File "/home/ivan/dev/python/geoenv/lib/python2.6/site-packages/Paver-1.0.4-py2.6.egg/paver/tasks.py", line 265, in parser
needs_tasks = [(environment.get_task(task), task) for task in self.needs_closure]
  File "/home/ivan/dev/python/geoenv/lib/python2.6/site-packages/Paver-1.0.4-py2.6.egg/paver/tasks.py", line 361, in needs_closure
needs = environment.get_task(top).needs
AttributeError: 'module' object has no attribute 'needs'

Investigate if this is not a bug caused by fix for grandparents closure (use getattr instead of direct access...)

Define tasks in dependency-aware way

(from http://code.google.com/p/paver/issues/detail?id=55)

call_task('paver.virtual.bootstrap') without virtualenv being installed

This produces following traceback:

Traceback (most recent call last):
File "/root/prasarny/Paver-1.0.3/paver/tasks.py", line 170, in _run_task
return do_task()
File "/root/prasarny/Paver-1.0.3/paver/tasks.py", line 167, in do_task
return func(**kw)
File "pavement.py", line 85, in bootstrap
call_task('paver.virtual.bootstrap')
File "/root/prasarny/Paver-1.0.3/paver/easy.py", line 80, in call
return self.__get_object()(_args, *_kw)
File "/root/prasarny/Paver-1.0.3/paver/tasks.py", line 129, in call_task
task()
TypeError: 'NoneType' object is not callable

IMO, this is misleading and unreadable. It would be nice that if virtualenv is not installed, value/import error would be rised and report virtualenv as missing dependency.

Tasks do not take cmdopts from their grand parents

The following pavement.py file shows the issue. The task t3 needs t2 and t2 needs t1, but the cmdopts defined in t1 cannot be passed to t3 in a command line invocation:

from paver.easy import *

@task
@cmdopts(
  (("aaa=","a","Ahhhhhhhhhhhhhhhhh"),)
)
def t1(options): print "t1 "

@task
@needs('t1')
@cmdopts(
  (("bbb=","b","Bbbbbbbb"),)
)
def t2(options):
  print "t2 " + options.aaa

@task
@needs('t2')
@cmdopts(
  (("ccc=","c","CCCCCCCCC"),)
)
def t3(options):
  print "t3 " + options.aaa

if I run:
$ paver help t2
---> paver.tasks.help

pavement.t2
-----------
Usage: paver pavement.t2 [options]

Options:
  -h, --help         display this help information
  -b BBB, --bbb=BBB  Bbbbbbbb
  -a AAA, --aaa=AAA  Ahhhhhhhhhhhhhhhhh

But the t3 task does not handle the -a option (comes from t1)

$ paver help t3
---> paver.tasks.help

pavement.t3
-----------
Usage: paver pavement.t3 [options]

Options:
  -h, --help         display this help information
  -c CCC, --ccc=CCC  CCCCCCCCC
  -b BBB, --bbb=BBB  Bbbbbbbb

If I try to run the t3 task with the -a parameter an error occurs:
$ paver t3 -a 11111111
Usage: paver pavement.t3 [options]

paver: error: no such option: -a

I've tested all this using the following versions:
$ paver --version
Paver 1.0.3

$ python --version
Python 2.6.6

I've fixed this by changing tasks.py, adding to the class Task the property needs_closure (that calculates all the tasks that are needed by a task transitively) and using it in the parser property. Here is the source code.

needs_closure property:
@Property
def needs_closure(self):
stack = [] + self.needs
rv = []
while stack:
top = stack.pop()
if (not top in rv):
rv.append(top)
needs = []
if (environment.get_task(top)):
needs = environment.get_task(top).needs
for t in needs:
stack.append(t)

    return rv

changes in parser property:
# needs_tasks = [(environment.get_task(task), task) for task in self.needs]
needs_tasks = [(environment.get_task(task), task) for task in self.needs_closure]

Can you put this fix in the official version of paver?

Thanks in advance,
Aureliano.

PS: I've sent yesterday an email to [email protected] with this issue, but I haven't seen a response and the email did not appear in the group archives. Is it moderated?

py2.6 tests are failing

path.py upgrade

New versions. cool new features.

Improve consistency of path

(Also think about upgrading to newest version)

Reported by project member dangoor, Jun 17, 2009 at http://code.google.com/p/paver/issues/detail?id=45

Juergen Hermann made some good suggestions in this thread:
http://groups.google.com/group/paver/browse_thread/thread/f806eaa4a89d6aed#

BTW, it might be a very good idea to "customize" (read: fix) it a
little more, namely in the realm of consistency and lack thereof.

What bit me lately is that it's path.basename(), but path.namebase (no
function but a property). I'd say go property all the way where a
method has property-like semantics.

You could even return a wrapped string like this...

class callable_str(str):
def call(self):
return self

and have it both ways.

And while we're at it, what I also cannot remember for the life of me
is the semantics of "a.symlink(b)". I'd very much like to have 2
optional keyword args of the form "a.symlink(target=b)" and "a.symlink
(link=b)". Not much work and a large improvement on the rtfm-again-and-
again front.

"a.symlink(c, link|target=b)" would raise an exception, of course.

Ah yeah, and "a.utime(b)" should work, instead of the tedious "a.utime
((b.atime, b.mtime))".

It's worth noting that we need to maintain backwards compatibility and provide
DeprecationWarnings for changed behavior.

Define behavior with both @cmdopts and @consume_args set

Latter now overwrites former, which is not what one generally wants.

Parse for cmdopts and remove it from args.

Add support for confirm()

Wors the same way as dry(), except is asks user for confirmation of particular step.

Also add some option like --noinput or --always-yes, also provide a way to disable it for particular task (i.e. when called from another task).

minilib task fails when run from paver-minilib.zip

Problem

When Paver's minilib task runs from paver-minilib.zip instead of a full Paver install, it fails pretty badly, truncating the zip file and preventing subsequent runs.

This happens, in particular, when pavement.py extends sdist to run minilib, as in the Getting Started example:

$ python setup.py sdist
---> pavement.sdist
---> paver.misctasks.generate_setup
Write setup.py
---> paver.misctasks.minilib
Generate paver-minilib.zip


Captured Task Output:
---------------------

---> pavement.sdist
---> paver.misctasks.generate_setup
Write setup.py
---> paver.misctasks.minilib
Generate paver-minilib.zip
Traceback (most recent call last):
  File "paver-minilib.zip/paver/tasks.py", line 170, in _run_task
  File "paver-minilib.zip/paver/tasks.py", line 166, in do_task
  File "paver-minilib.zip/paver/tasks.py", line 247, in __call__
  File "paver-minilib.zip/paver/tasks.py", line 187, in _run_task
  File "paver-minilib.zip/paver/tasks.py", line 167, in do_task
  File "paver-minilib.zip/paver/misctasks.py", line 45, in minilib
  File "paver-minilib.zip/paver/easy.py", line 16, in dry
  File "paver-minilib.zip/paver/misctasks.py", line 43, in generate_zip
  File "/usr/lib/python2.7/zipfile.py", line 1031, in write
    st = os.stat(filename)
OSError: [Errno 20] Not a directory: 'paver-minilib.zip/paver/__init__.py'

$ python setup.py sdist
Traceback (most recent call last):
  File "setup.py", line 6, in <module>
    import paver.tasks
ImportError: No module named paver.tasks

$ zipinfo paver-minilib.zip 
Archive:  paver-minilib.zip
Zip file size: 22 bytes, number of entries: 0
Empty zipfile.
$

This is also the cause of the old Google Code Issue 49, and GitHub #3 / #13. The fix for #13 added a partial workaround for when setup.py can use the installed Paver instead of paver-minilib.zip, but the underlying problem still remains.

Solution

I fixed two issues that prevent this from working:

minilib's generate_zip relies on direct filesystem access to read the input files. It can use pkgutil.get_data instead, which transparently supports Zip archives or any other import mechanism used by Python.
generate_zip truncates paver-minilib.zip before get_data has a chance to read the input files from it. This is easy to avoid by building the new Zip file in memory, and writing it to disk only once it's complete.

Using 'version' option causes conflicts

If you try to use an option named version, it's pulling the version from (I believe setuptools), even if it doesnt depend on it.

Misleading message if non-task is referred in @needs

Traceback (most recent call last):
File "/home/lukas.linhart/projects/tvcafe/venv/bin/paver", line 8, in
load_entry_point('Paver==1.1.0', 'console_scripts', 'paver')()
File "/home/lukas.linhart/projects/paver/paver/tasks.py", line 646, in main
_launch_pavement(args)
File "/home/lukas.linhart/projects/paver/paver/tasks.py", line 629, in _launch_pavement
_process_commands(args, auto_pending=auto_pending)
File "/home/lukas.linhart/projects/paver/paver/tasks.py", line 582, in _process_commands
task, args = _parse_command_line(args)
File "/home/lukas.linhart/projects/paver/paver/tasks.py", line 521, in _parse_command_line
args = task.parse_args(args)
File "/home/lukas.linhart/projects/paver/paver/tasks.py", line 323, in parse_args
parser = self.parser
File "/home/lukas.linhart/projects/paver/paver/tasks.py", line 265, in parser
needs_tasks = [(environment.get_task(task), task) for task in self.needs_closure]
File "/home/lukas.linhart/projects/paver/paver/tasks.py", line 364, in needs_closure
needs = environment.get_task(top).needs
AttributeError: 'function' object has no attribute 'needs'

`python setup.py sdist` failing

Here's what I get: https://gist.github.com/2998261