13

I have a project from which I would like to generate two separate python packages. I want to install these packages using pip.

In answers to this previous question, the general recommendation was to write two setup.py scripts: Multiple projects from one setup.py?

So I tried a structure like this:

/myproject
   setup_foo.py
   setup_bar.py
   /mypackage1
   /mypackage2
   ...

In setup_foo.py I set the script_name parameter:

from distutils.core import setup
setup(name = 'foo',
      version = '2.0.0',
      ...,
      script_name = 'setup_foo.py')

(I also tried the below without the parameter - according to the documentation it defaults to sys.argv[0])

I create foo-2.0.0.tar.gz using

python setup_foo.py sdist

But when I pip install foo-2.0.0.tar.gz, I get an error like this:

Unpacking .../foo-2.0.0.tar.gz
Running setup.py egg_info for package from file:///...foo-2.0.0.tar.gz
Traceback (most recent call last):
  File "<string>", line 14, in <module>
IOError: [Errno 2] No such file or directory: '/var/folders/wj/jv7n2pmn5d1g1jjx6khc8bx80000gn/T/pip-v3dujq-build/setup.py'
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "<string>", line 14, in <module>
IOError: [Errno 2] No such file or directory:
'/var/folders/wj/jv7n2pmn5d1g1jjx6khc8bx80000gn/T/pip-v3dujq-build/setup.py'

Am I missing some way of instructing pip to use setup_foo.py? Or should I place two scripts, both named 'setup.py', in separate directories?

Community
  • 1
  • 1
Niels Christensen
  • 508
  • 4
  • 9

2 Answers2

8

The question is why you put those projects into one directory. My recommendation would be to properly separate them, and then add them to a shared virtualenv via "setup.py develop -U". Been there, done that, works beautifully.

Otherwise, your next problem will be sharing a "setup.cfg", "MANIFEST.in", etc. In general you'll have a lot of unnecessary pain, each time you break assumptions of setuptools / distribute.

I suppose you chose the above structure so both packages are in the python path automagically, the "develop -U" makes it explicit, and quoting "import this":

Explicit is better than implicit.

pyroscope
  • 4,120
  • 1
  • 18
  • 13
  • Thanks for your answer! You're almost right about my reasons for choosing the structure I illustrated; I had two of them. First, I'm using PyDev/Eclipse and wanted to avoid inter-project dependencies if possible. Second, my two distributions share almost all of the packages in the project - they mainly differ in which command-line tools are included - so splitting them up into two or three separate projects seemed a bit excessive. If two distributions in one project rubs setuptools the wrong way, I may elect to have just one distribution and accept to deploy all scripts on all servers. – Niels Christensen Jan 17 '12 at 21:08
  • 1
    See http://code.google.com/p/pyroscope/source/browse/trunk/update-to-head.sh for some inspiration. If you install to a virtualenv (always a good idea, even on a production machine), you can selectively symlink the tool stubs, and thus publish a selected subset (see the "ln -nfs $(grep -l 'entry_point.*pyrocore==' $PWD/bin/*) ${BIN_DIR:-~/bin}/" command). – pyroscope Jan 18 '12 at 22:13
  • Clever! Yes, that's a simpler way of hiding/publishing subsets of sripts. – Niels Christensen Jan 20 '12 at 15:59
1

It looks like setuptools does not support setup scripts that are not named setup.py, contrary to distutils. I think it would be best to report the bug to the setuptools (bugs.python.org/setuptools) and distribute (on bitbucket) developers.

merwok
  • 6,779
  • 1
  • 28
  • 42
  • 1
    It may be a feature rather than a bug...the question is what effect "script_name" is supposed to have. The documentation is not particularly clear on that. – Niels Christensen Jan 20 '12 at 16:01
  • The distutils docs contain only this: http://docs.python.org/distutils/apiref#distutils.core.run_setup – merwok Jan 30 '12 at 16:44