Re: [Distutils] Building and installing packages on a (unix) system lacking network accesss
> On Dec 22, 2015, at 5:51 AM, KM wrote: > > Greetings distutils-sig, > > I have a project with an autogenerated structure - that is, I ran a "helper" > application which creates a directory structure and a setup.py for me. I am > trying to build this package in a virtualenv on an isolated machine, > necessiating the step of downloading all the prerequisite packages and making > them available. I have done this and I can successfully install most of the > prerequisites by passing "--no-index" and "-f " to pip, making my full > command-line: > > pip install -e . --no-index -f > > This works up until a certain point, where pip (or something launched by pip) > tries to download from the internet. [snip] This is in fact the entire point of saying --no-index; "don't download stuff from the internet". So it's working as designed. You need to make sure all your dependencies are available before you run that `pip install´ command. Have you? > I am hoping for some feedback or information that will allow me to install my > application with all of its dependencies downloaded from a locally-available > url or directory. Does anyone have any suggestions for me? You're doing this in vaguely the right way with `pip install -f --no-index´. As Ben Finney already pointed out, these are not distutils options so the whole thing with --global-option is a complete red herring, give up on that :-). In fact, as stated, your example works just fine: $ mkdir offline_stuff $ pip wheel --wheel-dir offline_stuff pytz Collecting pytz Saved ./offline_stuff/pytz-2015.7-py2.py3-none-any.whl Skipping pytz, due to already being wheel. $ mktmpenv ; cd - New python executable in tmp-a3e6ab08e84f351d/bin/python2.7 Also creating executable in tmp-a3e6ab08e84f351d/bin/python Installing setuptools, pip, wheel...done. virtualenvwrapper.user_scripts creating /Users/glyph/.virtualenvs/tmp-a3e6ab08e84f351d/bin/predeactivate virtualenvwrapper.user_scripts creating /Users/glyph/.virtualenvs/tmp-a3e6ab08e84f351d/bin/postdeactivate virtualenvwrapper.user_scripts creating /Users/glyph/.virtualenvs/tmp-a3e6ab08e84f351d/bin/preactivate virtualenvwrapper.user_scripts creating /Users/glyph/.virtualenvs/tmp-a3e6ab08e84f351d/bin/postactivate virtualenvwrapper.user_scripts creating /Users/glyph/.virtualenvs/tmp-a3e6ab08e84f351d/bin/get_env_details This is a temporary environment. It will be deleted when you run 'deactivate'. /Users/glyph (tmp-a3e6ab08e84f351d)$ pip install -f offline_stuff --no-index pytz Ignoring indexes: https://pypi.python.org/simple Collecting pytz Installing collected packages: pytz Successfully installed pytz-2015.7 (tmp-a3e6ab08e84f351d)$ python -c 'import pytz; print(pytz)' (tmp-a3e6ab08e84f351d)$ So if you could please provide a sample `setup.py´ or sample `requirements.txt´, along with exactly what unexpected output you got, it would be helpful in understanding what went wrong. This should be a minimal example demonstrating just the problem you're seeing, not your whole project; see http://sscce.org for a longer explanation. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Building and installing packages on a (unix) system lacking network accesss
KM writes: > This works up until a certain point, where pip (or something launched > by pip) tries to download from the internet. I tried adding > ''--global-option '--no-index -f '" to my options That specifies a *single* option to be passed to Distutils, containing spaces: “--no-index -f ”. > but this failed. I get the error: option --no-index -f not > recognized. Right, there is no “--no-index -f ” option recognised by Distutils. The “--global-option” option takes a single argument, which it passes to the ‘setup.py’ invocation. If you want multiple options passed that way, I think you need to use ‘--global-option’ several times. Once you use that, though, you'll find that Distutils also doesn't recognise “--no-index” nor “--find-links” options. What are you hoping those will do? -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but if they called them ‘Sad Meals’, kids wouldn't buy | _o__)them!” —_Pinky and The Brain_ | Ben Finney ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Reinstall with pip
Hi, I have an automation task that installs a python package from within the project dir using: pip install . What's the right way to reinstall the same package (same version)? --upgrade + --force-reinstall ? Is --no-deps recommended ? How about uninstalling and reinstalling ? Cheers, Carlos ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Building and installing packages on a (unix) system lacking network accesss
Greetings distutils-sig, I have a project with an autogenerated structure - that is, I ran a "helper" application which creates a directory structure and a setup.py for me. I am trying to build this package in a virtualenv on an isolated machine, necessiating the step of downloading all the prerequisite packages and making them available. I have done this and I can successfully install most of the prerequisites by passing "--no-index" and "-f " to pip, making my full command-line: pip install -e . --no-index -f This works up until a certain point, where pip (or something launched by pip) tries to download from the internet. I tried adding ''--global-option '--no-index -f '" to my options, but this failed. I get the error: option --no-index -f not recognized. This occurs right after "Running setup.py install for TurboGears2" in the pip output and after it has installed a number of other packages. [Using --global-option was a shot in the dark, after all]. The package it is looking for is pytz. It appears to not be finding the package when it looks for it the first time - i.e., in the build log, it doesn't announce that it has found the package, it just moves on to the next package. The system is a FreeBSD 10.2 system, vanilla except for some packages like bash, python2.7 and well openjdk which installs a bunch of X stuff, unfortunately. It runs as a VM under VirtualBox (latest version) on Windows 8 (kept "up-to-date" but on version 8 not 8.1). The pip in use is 7.0.3 under python 2.7 (because that is the latest version of pip available in the FreeBSD ports). I am hoping for some feedback or information that will allow me to install my application with all of its dependencies downloaded from a locally-available url or directory. Does anyone have any suggestions for me? KM ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setup.py install using pip
Thanks for digging that up. -Rob On 24 December 2015 at 06:35, Erik Bray wrote: > On Thu, Dec 10, 2015 at 5:12 PM, Robert Collins > wrote: >> On 8 December 2015 at 09:14, Erik Bray wrote: >>> On Mon, Dec 7, 2015 at 2:40 PM, Paul Moore wrote: On 7 December 2015 at 18:58, Erik Bray wrote: > I wasn't able to produce this problem. Even with --no-binary > specified pip installs (by default) with > --single-version-externally-managed. My prototype implicitly disables > the --pip flag if --single-version-externally-managed was specified > (true to the purpose of that flag). Ah - that was the bit I was missing, the --single-version-externally-managed flag can be used to trigger ignoring --pip. > What *is* a problem is if --pip is in setup.cfg, and one invokes `pip > install --egg .`. I wasn't quite able to make that go into an > infinite loop, but it did invoke pip.main recursively, and stuff broke > on the second invocation for reasons not clear to me. Yeah, but honestly I don't think pip install --egg is that important a use case. I may be wrong (there's lots of ways people use pip that I know nothing of :-)) but as a starting point it might be OK just to say that at the same time as the --pip flag was introduced, "pip install --egg" was deprecated (and we explicitly document that pip install --egg is known to interact badly with setup.py --pip). >>> >>> I'd be fine with that too. IIRC pip install --egg was introduced in >>> part to work around problems with namespace packages. This doesn't >>> completely eliminate the need for that workaround, but it does reduce >>> it. >> >> Huh? No, my understanding was that it was introduced solely to support >> interop with folk using 'easy-install', and its considered deprecated >> and delete-as-soon-as-practical. > > The original issue that motivated it did have to do with (lack of) > interoperability of different ways namespace packages are implemented: > > https://github.com/pypa/pip/issues/3 > > The fact that it introduced general backwards-compat for > easy-install-like installation was a side "benefit", useful I'm sure > to a few people. But otherwise as you say, was intended to be deleted > as soon as practical. > > Erik -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setup.py install using pip
On Thu, Dec 10, 2015 at 5:12 PM, Robert Collins wrote: > On 8 December 2015 at 09:14, Erik Bray wrote: >> On Mon, Dec 7, 2015 at 2:40 PM, Paul Moore wrote: >>> On 7 December 2015 at 18:58, Erik Bray wrote: I wasn't able to produce this problem. Even with --no-binary specified pip installs (by default) with --single-version-externally-managed. My prototype implicitly disables the --pip flag if --single-version-externally-managed was specified (true to the purpose of that flag). >>> >>> Ah - that was the bit I was missing, the >>> --single-version-externally-managed flag can be used to trigger >>> ignoring --pip. >>> What *is* a problem is if --pip is in setup.cfg, and one invokes `pip install --egg .`. I wasn't quite able to make that go into an infinite loop, but it did invoke pip.main recursively, and stuff broke on the second invocation for reasons not clear to me. >>> >>> Yeah, but honestly I don't think pip install --egg is that important a >>> use case. I may be wrong (there's lots of ways people use pip that I >>> know nothing of :-)) but as a starting point it might be OK just to >>> say that at the same time as the --pip flag was introduced, "pip >>> install --egg" was deprecated (and we explicitly document that pip >>> install --egg is known to interact badly with setup.py --pip). >> >> I'd be fine with that too. IIRC pip install --egg was introduced in >> part to work around problems with namespace packages. This doesn't >> completely eliminate the need for that workaround, but it does reduce >> it. > > Huh? No, my understanding was that it was introduced solely to support > interop with folk using 'easy-install', and its considered deprecated > and delete-as-soon-as-practical. The original issue that motivated it did have to do with (lack of) interoperability of different ways namespace packages are implemented: https://github.com/pypa/pip/issues/3 The fact that it introduced general backwards-compat for easy-install-like installation was a side "benefit", useful I'm sure to a few people. But otherwise as you say, was intended to be deleted as soon as practical. Erik ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
