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

user install of setuptools: easy_install -d option ignored #285

Closed
ghost opened this issue Nov 14, 2014 · 8 comments
Closed

user install of setuptools: easy_install -d option ignored #285

ghost opened this issue Nov 14, 2014 · 8 comments

Comments

@ghost
Copy link

ghost commented Nov 14, 2014

Originally reported by: bubla (Bitbucket: bubla, GitHub: bubla)


I have encountered the following case with setuptools installed using easy_install with the --user option (reason for the user installation: The system version was outdated).
The new setuptools provide their easy_install command and I have tried to install an egg to a given directory like this:

easy_install -d ~/test ../imreg_dft-0.6.0-py2.7.egg

However, instead of complaining that the target directory is not in PYTHONPATH, it didn't even try to install it there and went directly to the user's Python directory, i.e. ~/Library/Python/2.7/lib/python/site-packages (that's on OSX).

After investigation, we have discovered that the initialize_options function in easy_install.py:150 sets the self.user property, although --user hasn't been passed on command-line.
Then, it most likely results in self.install_dir being silently overwritten on easy_install.py:276 (but we aren't sure since we are not familiar with the purelib and stuff).
Anyway, the --user and --install-dir arguments to easy_install are contradictory, so setting user internally especially if install-dir has been set by the user looks like bug.

I propose not doing this if potentially conflicting arguments have been supplied. If this is too much, then this behavior should be documented and user should be clearly warned that his request is going to be ignored.


@ghost
Copy link
Author

ghost commented Nov 14, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


The --user option was added for Python 2.6, so it's quite possible this conflict has been around since then.-

Your analysis seems sound.

Can you propose a fix in a pull request?

@ghost
Copy link
Author

ghost commented Nov 18, 2014

Original comment by bubla (Bitbucket: bubla, GitHub: bubla):


I think that the fix in pull request #109 should do the trick.
I can see that @RonnyPfannschmidt is the author of incriminated lines in the code, so he should also be part of the discussion.

@ghost
Copy link
Author

ghost commented Mar 6, 2015

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Merged in milinnovations/setuptools (pull request #109)

Different treatment of --user option to easy_install (refs #285)

@ghost
Copy link
Author

ghost commented Mar 6, 2015

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Different treatment of --user option to easy_install (refs #285)

@ghost
Copy link
Author

ghost commented Mar 6, 2015

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Merged in milinnovations/setuptools (pull request #109)

Different treatment of --user option to easy_install (refs #285)

@ghost
Copy link
Author

ghost commented Mar 6, 2015

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Update test to match new expectation following pull request #109. Refs #285.

@ghost
Copy link
Author

ghost commented Mar 7, 2015

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Released as 14.0

@ghost
Copy link
Author

ghost commented Mar 7, 2015

Original comment by bubla (Bitbucket: bubla, GitHub: bubla):


Great to hear that, thank you!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

0 participants