[Distutils] pip installing scripts into another virtualenv

As part of a package management tool , I'm trying to use pip to install python packages into a virtualenv, from python code (via subprocess), into a different virtualenv than the virtualenv my python process is running in (if any). I have this *mostly* working

[Distutils] Re: pip installing scripts into another virtualenv

Yes, why not simply invoke the pip installed in the virtualenv into which you want to install the packages? It doesn't seem like you'd need to "re-architect" anything insomuch as simply change "pip" in your argument list to the path to the pip inside the virtualenv you're targeting. --Chris On Fr

[Distutils] Re: pip installing scripts into another virtualenv

The main downside to invoking pip in the virtualenv is that it means I have to have pip installed within the virtualenv, which is something I haven't wanted to commit to in the interest of creating slim virtualenvs for bundling with apps. But you are probably right and I need to accept that. On Fr

[Distutils] Re: pip installing scripts into another virtualenv

I am confused. If you’re installing things with subprocess, and is using virtual environments anyway, wouldn’t it be simpler to use the pip inside the virtual environment directly? Instead of using a (random) pip to install into the environment, you can instead do [virtualenv-path]/[script-pre

[Distutils] Re: pip installing scripts into another virtualenv

Isn't virtualenv's default behavior to install pip automatically when a virtualenv is created? https://virtualenv.pypa.io/en/stable/userguide/#usage (That is, I don't think you need to "force" pip to be installed, but rather simply rely on default behavior.) --Chris On Fri, Sep 14, 2018 at 12:50

[Distutils] Re: pip installing scripts into another virtualenv

On Fri, 14 Sep 2018 at 08:16, Alex Becker wrote: > Is there a way around this behavior? Am I crazy to even try to install into a > different virtualenv? Or do I have to re-architect my code to call pip in the > target virtualenv (which may require me forcing pip to be installed, > depending on

[Distutils] Re: pip installing scripts into another virtualenv

To add to these responses, Tzu Ping and I have tried this in a myriad of creative ways and mostly haven’t been successful while relying on pip’s cli. The right answer is to invoke the virtualenv pip, it’s just easier -D Dan Ryan // pipenv maintainer gh: @techalchemy > On Sep 14, 2018, at 4:09

[Distutils] Re: disable building wheel for a package

I'm curious: what data does it attempt to install and where? Have you created a ticket for this somewhere? ke, 2018-09-12 kello 15:56 -0400, sashk kirjoitti: > > > > > I agree with Nathaniel - the correct solution is to fix your > > > package > > > so that can be built as a wheel which correctl

[Distutils] Re: disable building wheel for a package

On 2018-09-14 12:55, Alex Grönholm wrote: I'm curious: what data does it attempt to install and where? Have you created a ticket for this somewhere? The OP mentioned absolute paths. However, it really sounds like a bad idea to hard-code an absolute installation path. Let's consider it a featu

[Distutils] Re: disable building wheel for a package

Yes that feels very dangerous to me. From the github thread it sounds like setuptools *does* support it. I would be inclined to deprecate support for that in setuptools if that's the case (though obviously since setup.py is a regular python file you can write your own code to do whatever you wan

[Distutils] Re: disable building wheel for a package

On Fri, 14 Sep 2018 at 12:43, Jeroen Demeyer wrote: > > On 2018-09-14 12:55, Alex Grönholm wrote: > > I'm curious: what data does it attempt to install and where? Have you > > created a ticket for this somewhere? > > The OP mentioned absolute paths. However, it really sounds like a bad > idea to h

[Distutils] Re: disable building wheel for a package

  14.09.2018, 08:37, "Paul Moore" :On Fri, 14 Sep 2018 at 12:43, Jeroen Demeyer wrote: On 2018-09-14 12:55, Alex Grönholm wrote: > I'm curious: what data does it attempt to install and where? Have you > created a ticket for this somewhere? The OP mentioned absolute paths. Howev

[Distutils] Re: disable building wheel for a package

No one wants wheel to be able to install things outside of the virtualenv. What people have repeatedly asked for is the ability to install things somewhere besides $VIRTUAL_ENV/lib/python#.#/site-packages/, places like $VIRTUAL_ENV/etc/ for example. Should all the config files, documentation, data,

[Distutils] Re: disable building wheel for a package

On Fri, 14 Sep 2018 at 14:51, sashk wrote: > No, I'm not installing anything into standard unix locations. My package is > for internal use, so we had a luxury to write it specifically for use with > virtual environment. > > We need to install Jupyter kernels (and other files) into > $VIRTUAL_E

[Distutils] Re: disable building wheel for a package

I’m wondering though, why? The wheel format already offers a data directory, couldn’t it be used for most of the things mentioned? > On 14/9/2018, at 22:25, Daniel Holth wrote: > > No one wants wheel to be able to install things outside of the virtualenv. > What people have repeatedly asked f

[Distutils] Re: disable building wheel for a package

It can be hard to predict where data went at runtime. Maybe we could record its path in .dist-info during the install. I think it may also not be clear how to put files into wheel's data directory from setup.py. If we added more categories it would allow the installer to override e.g. just the con

[Distutils] Re: disable building wheel for a package

On Fri, 14 Sep 2018 at 16:03, Daniel Holth wrote: > > It can be hard to predict where data went at runtime. I don't think it's "hard to predict". I *do* think it's badly documented/not standardised. See my previous note - pip installs into the install_data location that setuptools/distutils choos

[Distutils] Re: disable building wheel for a package

A corner case is where the package is importable because it is on $PYTHONPATH and so the $virtual_env at runtime is different than the one at install time. That is why it might be useful to store the data directory per-package. wheel.install.get_install_paths(package_name) shows where things would

[Distutils] Re: disable building wheel for a package

On 2018-09-14 15:49, sashk wrote: Do I understand correctly, that when using relative paths in the data_files and installing package into virtual environment, installation prefix is sys.prefix and it is the same as $VIRTUAL_ENV? Indeed, unless you specifically configure things in a non-default

[Distutils] Re: disable building wheel for a package

On 2018-09-14 16:39, Paul Moore wrote: My understanding (and I'm not an expert here, so hopefully someone else will confirm or correct) is that yes, the data directory is installed to "the installation root", which is $VIRTUAL_ENV for a virtualenv, and "something else" for non-virtualenvs (I thin

[Distutils] Re: disable building wheel for a package

On Fri, 14 Sep 2018 at 17:05, Jeroen Demeyer wrote: > > On 2018-09-14 16:39, Paul Moore wrote: > > My understanding (and I'm not an expert here, so hopefully someone > > else will confirm or correct) is that yes, the data directory is > > installed to "the installation root", which is $VIRTUAL_ENV

[Distutils] Re: disable building wheel for a package

FWIW I think it’s perfectly reasonable to expand the categories we have, it might also let us do things like exclude some categories from being installed on systems they don’t make sense on. e.g. installing a man page on Windows probably doesn’t make very much sense, so we could just exclude it.

[Distutils] Re: disable building wheel for a package

On Fri, Sep 14, 2018, 07:27 Daniel Holth wrote: > No one wants wheel to be able to install things outside of the virtualenv. > What people have repeatedly asked for is the ability to install things > somewhere besides $VIRTUAL_ENV/lib/python#.#/site-packages/, places like > $VIRTUAL_ENV/etc/ for