Workaround distutils bug #113

proofit404 · 2015-09-12T08:15:45Z

Ignore distutils prefix config parameter during package installations.

oiwn · 2015-09-14T22:03:30Z

 File "/usr/local/lib/python2.7/site-packages/setuptools/command/install.py", line 38, in finalize_options             |requirements.txt orig.install.finalize_options(self)
File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/install\
.py", line 264, in finalize_options                                                                                    
    "must supply either home or prefix/exec-prefix -- not both" 
DistutilsOptionError: must supply either home or prefix/exec-prefix -- not both^[[0m/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'anaconda_mode.py':

Do you mean this one? I just updated packages and can't use emacs because of it.

proofit404 · 2015-09-15T05:37:52Z

Yes, I mean exactly this problem.

proofit404 · 2015-09-15T05:38:46Z

You can find temporary workaround in #114

oiwn · 2015-09-15T22:25:13Z

Already fixed, thank you.

offbyone · 2015-10-05T15:31:04Z

@proofit404 is there any chance you've made progress on this? I appreciate that this is OSS, so no demands, but if you happen to have the time I'd love to see a fix trickle out.

Thank you.

proofit404 · 2015-10-05T15:54:59Z

There are a lot of work to do on this project to make it pleasant for every one. Unfortunately I doesn't have enough time to work on each issue. Currently make anaconda-mode work over tramp have biggest priority for me. Maybe I can comeback to this issue after finishing tramp branch.

Thanks for your patience.
Regards, Artem.

introom · 2016-05-05T12:14:17Z

I encountered the same problem with the latest debian sid.

The pip version is 8.1.1. There is no shipped distutils.cfg.

I ended up removing debian's python-pip package and uses the get-pip script to get an upstream version of pip. That one also is of version 8.1.1.

proofit404 · 2016-05-05T12:28:06Z

System wide pip installation doesn't work and pip installed with get-pip script works without any different change in the system?

introom · 2016-05-05T13:27:31Z

System wide pip installation doesn't work
yes

pip installed with get-pip script works without any different change in the system?
no change required.

proofit404 · 2016-05-05T13:39:38Z

What Linux distribution (with full version) do you use? I will try to reproduce this in virtual machine.

introom · 2016-05-05T16:31:58Z

debian sid 64bit.

proofit404 · 2016-05-05T17:22:33Z

What installation method did you use? netinstall/desktop with ui installer

introom · 2016-05-06T02:35:48Z

I think it doesn't matter here, though.

I installed the latest Debian sid with virtualbox. The installation is done in expert-mode, and no X software is installed. So all happens within tui.

If you open up a Debian 64bit testing instance on google cloud platform, you will suffer the same issue.
I've also tested that on Linode with the same setup. Again, it will fail if you choose to install the debian packaged python-pip.

proofit404 · 2016-06-29T12:00:17Z

Maybe we can get rid of this bug finally. I need help from person with OS X.

Given: python (2.7 for example) installed with homebrew. Code below must fail with weird distutils error.

mkdir $HOME/.emacs.d/anaconda-mode/test/
pip install -t $HOME/.emacs.d/anaconda-mode/test/ anaconda-mode

At the same time some thing like this may works:

PYTHONPATH=$HOME/.emacs.d/anaconda-mode/test/ easy_install -d $HOME/.emacs.d/anaconda-mode/test/ -a anaconda_mode

Any volunteer to help?

ttylec · 2016-06-30T11:36:21Z

I confirm (OS X 10.11.5) that the first results in error and the latter installs without any problems. With python from homebrew.

proofit404 · 2016-06-30T11:46:00Z

@ttylec Thanks for your help!

sickHamm · 2016-07-03T09:07:43Z

@proofit404 Just want you know. maybe helpful.

Debian Test has same bug；
but pip install --system --target=~/.emacs.d/anaconda-mode/0.1.2/ anaconda_mode work well；
I think the reason is pip --target imply --prefix； and '--user' and '--prefix' could not work togther， and on Debian systems the --user is default. the Mac OS X 's pip may default --user too.

--user Install to the Python user install directory for your platform. Typically ~/.local/,

On Debian systems, this is the default when running outside of a virtual environment

and not as root.
--system Install using the system scheme (overrides --user on Debian systems)

ERROR: Can not combine '--user' and '--prefix' as they imply different installation locations

pip3 install --user --prefix anaconda_mode
ERROR: Can not combine '--user' and '--prefix' as they imply different installation locations

sickHamm · 2016-07-03T09:13:36Z

And why not create a virtualenv for anaconda server but Install using the system scheme ; just like jedi.el .

proofit404 · 2016-07-05T10:09:59Z

@sickHamm Thanks for information you provide.

The reason to install anaconda_mode python package into directory and not in virtual environment is pretty straightforward. Last time I saw jedi.el the way it works with your own virtual environments was ugly. I don't know if it changes. If I recall correctly you need add side packages from your own virtual environment as a buffer local variable to run separate jedirpcserver for each buffer. There is a special package to simplify this. I don't like this approach at all.

Anaconda mode make it difference. All that you need is activate your project virtual environment as you usually does with python.el (set global variable ones). Anaconda mode takes care of the rest of process including installation and server monitoring. The simplest way to implement this just have a directory where anaconda_mode.py and its dependencies lives.

Hope this clarify taken design decisions a little.

Regards, Artem.

sickHamm · 2016-07-05T11:51:20Z

thanks for your explanation.

and my explanation maybe not very clear;
in short,
when install anaconda_mode maybe should use --system overrides --user, at least on debians

Debian Test has same bug；
but pip install --system --target=~/.emacs.d/anaconda-mode/0.1.2/ anaconda_mode work well；
I think the reason is pip --target imply --prefix； and '--user' and '--prefix' could not work togther， and on Debian systems the --user is default. the Mac OS X 's pip may default --user too.

proofit404 · 2016-07-05T11:54:39Z

At this point we decide to move from pip to easy_install. It achieve same goal without flags conflict. You can follow related discussion in #186

Pip is a wonderful utility, yet hopelessly not friendly to scripts. Its deficiencies could be easily described as bugs, and then we could insist on upstream fixing them. Until then, installation procedure would remain broken in a number of configurations. Afterwards, users would need to pay attention to use sufficiently new PIP. The problems are at least the following: - If PIP is installed with prefix option set in distutils.cfg, e.g., the way homebrew does it on mac, command line option -t will not override it, but instead a configuration conflict will be reported. - Debian-based distributions patch PIP to default to using --user installation scheme, if not run within a virtualenv, and provide debian-specific --system option to override this behaviour. The default, yet again, conflicts with -t option, instead of being overridden by the latter. By comparison, easy_install does not suffer from either of those. This commit replaces installation using pip with easy_install. As a result, the packages are installed as eggs, which means that server setup launch procedure had to be replaced with a python script as well. Additionally, since eggs are not accessible through their parent directory and need to be added to sys.path separately, the server detection command also needed to be altered, so that instead of just checking the installation directory, it would check immediate subdirectories. anaconda_mode present in one of the subdirectories would not guarantee that it works, so it then also tries to find that path in sys.path. This change is entirely backward compatible: - The check-installation-command will correctly detect legacy installation made by pip. - the server-command will successfully run such installation. Hence the the needed version of anaconda_mode python package has not yet been modified, to allow for separate deployment and easier testing. It is also worth noting that site.addsitedir() ends up adding eggs before system site packages, so that the locally installed version of python package will take precedence over any global installation. The same applies to legacy installation in pip-style: while the absolute path version of current directory will be added to the end of sys.path, the current directory pattern remains in front of system directory, so that anaconda_mode will be imported from the current directory. This should fix pythonic-emacs#113 and pythonic-emacs#114.

proofit404 added the enhancement label Sep 12, 2015

This was referenced Sep 12, 2015

Can't open file 'anaconda_mode.py' #106

Closed

six package fails to install via pip #91

Closed

can't start 'anaconda-mode' server #114

Closed

proofit404 mentioned this issue Oct 13, 2015

OS X 10.8, python2.7 via Homebrew: "DistutilsOptionError: must supply either home or prefix/exec-prefix -- not both" #129

Closed

proofit404 mentioned this issue Jan 10, 2016

anaconda-mode does not start with Homebrew installed Python #154

Closed

pitkali mentioned this issue Jun 27, 2016

Force system scheme for installation of pip packages #186

Closed

pitkali mentioned this issue Jul 11, 2016

Replace pip #187

Merged

proofit404 closed this as completed in #187 Jul 17, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Workaround distutils bug #113

Workaround distutils bug #113

proofit404 commented Sep 12, 2015

oiwn commented Sep 14, 2015

proofit404 commented Sep 15, 2015

proofit404 commented Sep 15, 2015

oiwn commented Sep 15, 2015

offbyone commented Oct 5, 2015

proofit404 commented Oct 5, 2015

introom commented May 5, 2016

proofit404 commented May 5, 2016

introom commented May 5, 2016

proofit404 commented May 5, 2016

introom commented May 5, 2016

proofit404 commented May 5, 2016

introom commented May 6, 2016

proofit404 commented Jun 29, 2016

ttylec commented Jun 30, 2016 •

edited

proofit404 commented Jun 30, 2016

sickHamm commented Jul 3, 2016 •

edited

On Debian systems, this is the default when running outside of a virtual environment

sickHamm commented Jul 3, 2016 •

edited

proofit404 commented Jul 5, 2016

sickHamm commented Jul 5, 2016

proofit404 commented Jul 5, 2016

Workaround distutils bug #113

Workaround distutils bug #113

Comments

proofit404 commented Sep 12, 2015

oiwn commented Sep 14, 2015

proofit404 commented Sep 15, 2015

proofit404 commented Sep 15, 2015

oiwn commented Sep 15, 2015

offbyone commented Oct 5, 2015

proofit404 commented Oct 5, 2015

introom commented May 5, 2016

proofit404 commented May 5, 2016

introom commented May 5, 2016

proofit404 commented May 5, 2016

introom commented May 5, 2016

proofit404 commented May 5, 2016

introom commented May 6, 2016

proofit404 commented Jun 29, 2016

ttylec commented Jun 30, 2016 • edited

proofit404 commented Jun 30, 2016

sickHamm commented Jul 3, 2016 • edited

On Debian systems, this is the default when running outside of a virtual environment

ERROR: Can not combine '--user' and '--prefix' as they imply different installation locations

sickHamm commented Jul 3, 2016 • edited

proofit404 commented Jul 5, 2016

sickHamm commented Jul 5, 2016

proofit404 commented Jul 5, 2016

ttylec commented Jun 30, 2016 •

edited

sickHamm commented Jul 3, 2016 •

edited

sickHamm commented Jul 3, 2016 •

edited