Requires system-wide pip installation. about pip2pi HOT 10 CLOSED

Would a --pip-executable flag fix this problem? Ex:

$ pip2pi --pip-executable env/bin/pip …

On 2013-01-06, at 11:29, ToBeReplaced [email protected] wrote:

This assumes that there is a global pip installation. I am bootstrapping pip in to virtual environments with no global pip. Alternatively, you could use something like "os.path.join(os.path.dirname(sys.executable), 'pip')".

from pip2pi.

Yes, that would get the job done, but it doesn't feel quite right. It feels like the pip from the python interpreter that installed pip2pi should be used. I've never looked at internals of distutils/pip so I'm not sure how they accomplish it. What do you think?

from pip2pi.

On 2013-01-06, at 1:54 PM, ToBeReplaced [email protected] wrote:

Yes, that would get the job done, but it doesn't feel quite right. It feels like the pip from the python interpreter that installed pip2pi should be used.

mmm… ok, after some thought, this seems like a reasonable argument.

In fact, even more reasonable would be to import the pip package and call into it directly:

import pip
pip.main(["bundle", "-b", build_dir, bundle_zip] + argv[2:])

That, combined with adding pip as a requirement in setup.py, seems like The Right thing to do.

The downside of this is that it will subtly change the behaviour… As previously pip2pi could be installed in the system, but used from a virtualenv… But provided we can fall back to this (along with a deprecation warning), I think that should be fine:

try:
    import pip
except ImportError as e:
    import warnigns
    warnings.warn((
        "could not import pip package (%r), falling back to calling pip executable. "
        "This behaviour is deprecated and will eventually be removed."
    ) %(e, ))
    pip = None

def call_pip(argv):
    if pip is None:
        check_call(["pip"] + argv)
    else:
        pip.main(argv)

Sound reasonable?

I've never looked at internals of distutils/pip so I'm not sure how they accomplish it. What do you think?

How they accomplish which?

phone: (416) 906-0403
pgp: B230230D

from pip2pi.

That sounds like a good solution to me. Importing pip and adding it as a setup requirement makes a lot of sense. I'm not sure when it's a good idea to use a system-install of pip2pi from within a virtual env, so I agree with preserving the behavior and adding a warning.

As for the "how do they accomplish it" comment... That was referring to figuring out where the python environment's executables are. It doesn't apply because you can import pip directly, which is much better.

from pip2pi.

Awesome. Are you able to submit a pull request? Otherwise, I'll get to this after the holidays.

On 2013-01-06, at 16:20, ToBeReplaced [email protected] wrote:

That sounds like a good solution to me. Importing pip and adding it as a setup requirement makes a lot of sense. I'm not sure when it's a good idea to use a system-install of pip2pi from within a virtual env, so I agree with preserving the behavior and adding a warning.

from pip2pi.

Wouldn’t it be enough to pass os.environ to check_call? That way, you let the OS respect $PATH when trying to find the pip executable.

from pip2pi.

Wait… Doesn't check_call with shell=True automatically use $PATH?

from pip2pi.

shell=True means unsafe=True :) That aside, I’m not sure.

from pip2pi.

For example, in fedora 19 they changed pip executable to [pip-python | python-pip] and that broke pip2tgz, importing pip would solve this in a cleaner way.

A quick solve is making a symbolic link to the new name. "ln -s /usr/bin/pip-python /usr/bin/pip"

from pip2pi.

Ah ha! This has been fixed by #19 and pushed in version 0.5.0!

from pip2pi.