Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for '--setup-prefix' for path to setup.py #572

Closed
derks opened this issue Jun 9, 2012 · 1 comment
Closed

Support for '--setup-prefix' for path to setup.py #572

derks opened this issue Jun 9, 2012 · 1 comment
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@derks
Copy link

derks commented Jun 9, 2012

For standard python packages, having a setup.py in the root directory of your source repo makes perfect sense. However, I have several large projects that are broken up into multiple installable python packages, within the same git repo. For example:

http://github.com/derks/cement

In the above example, all python installable packages are under a './src/' prefix. The reason for seperate python packages is because of externel dependencies. The core library has zero external dependencies, therefore any extensions that do have external dependencies are packaged seperately, since they are optional extensions... and I don't want to enforce installing external deps for things people don't want.

My issue is, I can not use the '-e' option with this type of git repo because there is no 'setup.py' in the root directory of the git repo. What I would like to see is an added '--setup-prefix' or similar option. For example:

pip install --setup-prefix='./src/cement2' -e git+git://github.com/derks/cement.git#egg=cement2

Or for the other packages for example:

pip install --setup-prefix='./src/cement2.ext.configobj' -e git+git://github.com/derks/cement.git#egg=cement2.ext.configobj

I would imagine that '--setup-prefix' would trigger a simple call to 'os.chdir()' to change the working directory after checkout.

My only alternative is to maintain all secondary python packages (extensions) in their own git repo... which is not ideal because I maintain all as one source (versions, testing, continuous integration, etc). Seems like a relatively simple solution which would allow pip to support 'non-standard' directory structures.

Thank you!

@pnasrat
Copy link
Contributor

pnasrat commented Jun 9, 2012

See issue #526

@pnasrat pnasrat closed this as completed Jun 9, 2012
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 6, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

2 participants