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

Forced use of --allow-external and --allow-unverified very inconvenient and not very intuitive #1423

Closed
bladeoflight16 opened this Issue Jan 4, 2014 · 43 comments

Comments

Projects
None yet
@bladeoflight16

bladeoflight16 commented Jan 4, 2014

Recently, I tried to install a module and got the following error message:

(virtualenv) C:\[snip]\trunk>pip install pypyodbc
Downloading/unpacking pypyodbc
  Could not find any downloads that satisfy the requirement pypyodbc
  Some externally hosted files were ignored (use --allow-external pypyodbc to allow).
Cleaning up...
No distributions at all found for pypyodbc
Storing debug log for failure in C:\Users\[snip]\pip\pip.log

I immediately tried to following command and was confused by the output:

(virtualenv) C:\[snip]\trunk>pip install --allow-external pypyodbc
You must give at least one requirement to install (see "pip help install")

A moment of Googling and reading some documention helped clear up the issue and I settled on this command rather than duplicate the package name:

(virtualenv) C:\[snip]\trunk>pip install --allow-all-external pypyodbc
Downloading/unpacking pypyodbc
  Could not find any downloads that satisfy the requirement pypyodbc
  Some insecure and unverifiable files were ignored (use --allow-unverified pypyodbc to allow).
Cleaning up...
No distributions at all found for pypyodbc
Storing debug log for failure in C:\Users\[snip]\pip\pip.log

At this point, I was rather annoyed, and I tried to use an "all" variant of the --allow-unverified argument, which of course didn't exist:

(virtualenv) C:\[snip]\trunk>pip install --allow-all-external --allow-all-unverified pypyodbc

Usage:
  pip install [options] <requirement specifier> ...
  pip install [options] -r <requirements file> ...
  pip install [options] [-e] <vcs project url> ...
  pip install [options] [-e] <local project path> ...
  pip install [options] <archive url/path> ...

no such option: --allow-all-unverified

I finally got it to work with --allow-unverified pypyodbc, but I feel this was a very poor user experience. I checked, and using --allow-unverified by itself doesn't work:

(virtualenv) C:\[snip]\trunk>pip install --allow-unverified pypyodbc pypyodbc
Downloading/unpacking pypyodbc
  Could not find any downloads that satisfy the requirement pypyodbc
  Some externally hosted files were ignored (use --allow-external pypyodbc to allow).

Having to type out both arguments seems unnecessarily bulky and tedious to me. I understand the value in having the ability to be more specific, but I suspect that in 99% of the use cases where this is an issue, users will want to bypass both. As such, there should be a combined argument that tells pip "I don't care about the security right now. Just install this." I haven't come up with a good name for such an argument, but there should probably be individual and all variants of this argument. If users using such an argument with poor judgement is considered to be an issue, I would point out the "We're all adults here" mentality set forth by the Python community.

Furthermore, I think the error message could be improved. It was not immediately obvious to me that the error message was suggesting I repeat the package name with the argument. It may be worthwhile to suggest an entire command line so that this is clear, or perhaps suggesting the all variant in addition to the package variant will make more clear that the package name is part of the argument.

@argriffing

This comment has been minimized.

Show comment
Hide comment
@argriffing

argriffing Jan 6, 2014

I went through this too. More command line examples in the docs would have helped.

argriffing commented Jan 6, 2014

I went through this too. More command line examples in the docs would have helped.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 7, 2014

Member

I think it probably makes sense that if you specify --allow-unverified FOO that it implies --allow-external FOO as well.

As far as an --allow-all-unverified that was asked for in #1268 which captures the reasoning behind there not being an all variant of that option and my opinion still is aligned with my posts in that issue.

Member

dstufft commented Jan 7, 2014

I think it probably makes sense that if you specify --allow-unverified FOO that it implies --allow-external FOO as well.

As far as an --allow-all-unverified that was asked for in #1268 which captures the reasoning behind there not being an all variant of that option and my opinion still is aligned with my posts in that issue.

@flyte

This comment has been minimized.

Show comment
Hide comment
@flyte

flyte Jan 7, 2014

I was completely stumped by this as well.

When trying to pip install uwsgi==1.2.3:

  Could not find a version that satisfies the requirement uwsgi==1.2.3 (from versions: 1.4.10, 1.4.9, 1.9.1, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.15, 1.9.16, 1.9.17.1, 1.9.17, 1.9.18.1, 1.9.18.2, 1.9.18, 1.9.19, 1.9.2, 1.9.20, 1.9.21.1, 1.9.21, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.9.8, 1.9.9, 1.9, 2.0)
  Some externally hosted files were ignored (use --allow-external to allow).

and after I apparently got the allow-external part right

  Could not find a version that satisfies the requirement uwsgi==1.2.3 (from versions: 1.4.10, 1.4.9, 1.9.1, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.15, 1.9.16, 1.9.17.1, 1.9.17, 1.9.18.1, 1.9.18.2, 1.9.18, 1.9.19, 1.9.2, 1.9.20, 1.9.21.1, 1.9.21, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.9.8, 1.9.9, 1.9, 2.0)
  Some insecure and unverifiable files were ignored (use --allow-unverified uwsgi to allow).

So I try all of the following:

pip --allow-external install uwsgi==1.2.3
pip install --allow-external uwsgi==1.2.3
pip install --allow-external uwsgi uwsgi==1.2.3
pip install --allow-external uwsgi==1.2.3 uwsgi==1.2.3
pip install uwsgi==1.2.3 --allow-external
pip install --allow-all-external uwsgi==1.2.3
pip install --allow-unverified --allow-external uwsgi==1.2.3
pip install --allow-external uwsgi==1.2.3 --allow-unverified uwsgi==1.2.3 uwsgi==1.2.3

and many more, until I finally figure out the way that works:

pip install --allow-external uwsgi --allow-unverified uwsgi uwsgi==1.2.3

flyte commented Jan 7, 2014

I was completely stumped by this as well.

When trying to pip install uwsgi==1.2.3:

  Could not find a version that satisfies the requirement uwsgi==1.2.3 (from versions: 1.4.10, 1.4.9, 1.9.1, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.15, 1.9.16, 1.9.17.1, 1.9.17, 1.9.18.1, 1.9.18.2, 1.9.18, 1.9.19, 1.9.2, 1.9.20, 1.9.21.1, 1.9.21, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.9.8, 1.9.9, 1.9, 2.0)
  Some externally hosted files were ignored (use --allow-external to allow).

and after I apparently got the allow-external part right

  Could not find a version that satisfies the requirement uwsgi==1.2.3 (from versions: 1.4.10, 1.4.9, 1.9.1, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.9.14, 1.9.15, 1.9.16, 1.9.17.1, 1.9.17, 1.9.18.1, 1.9.18.2, 1.9.18, 1.9.19, 1.9.2, 1.9.20, 1.9.21.1, 1.9.21, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.9.8, 1.9.9, 1.9, 2.0)
  Some insecure and unverifiable files were ignored (use --allow-unverified uwsgi to allow).

So I try all of the following:

pip --allow-external install uwsgi==1.2.3
pip install --allow-external uwsgi==1.2.3
pip install --allow-external uwsgi uwsgi==1.2.3
pip install --allow-external uwsgi==1.2.3 uwsgi==1.2.3
pip install uwsgi==1.2.3 --allow-external
pip install --allow-all-external uwsgi==1.2.3
pip install --allow-unverified --allow-external uwsgi==1.2.3
pip install --allow-external uwsgi==1.2.3 --allow-unverified uwsgi==1.2.3 uwsgi==1.2.3

and many more, until I finally figure out the way that works:

pip install --allow-external uwsgi --allow-unverified uwsgi uwsgi==1.2.3
@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 7, 2014

Member

Yea sorry for the bad message- Part of that is because in some cases we can't tell if there's an unverified file available until after we've allowed external. But in 1.5.1 we'll be switching the message to give a full command, and we'll be switching it so --allow-unverified FOO implies --allow-external FOO.

Member

dstufft commented Jan 7, 2014

Yea sorry for the bad message- Part of that is because in some cases we can't tell if there's an unverified file available until after we've allowed external. But in 1.5.1 we'll be switching the message to give a full command, and we'll be switching it so --allow-unverified FOO implies --allow-external FOO.

@flyte

This comment has been minimized.

Show comment
Hide comment
@flyte

flyte Jan 7, 2014

Thanks 👍

flyte commented Jan 7, 2014

Thanks 👍

@ZeerDonker

This comment has been minimized.

Show comment
Hide comment
@ZeerDonker

ZeerDonker Jan 8, 2014

The error message that pip gives should also give information about the

--allow-all-external

option in case a requirement file is being used.

ZeerDonker commented Jan 8, 2014

The error message that pip gives should also give information about the

--allow-all-external

option in case a requirement file is being used.

@bladeoflight16

This comment has been minimized.

Show comment
Hide comment
@bladeoflight16

bladeoflight16 Jan 9, 2014

I think some examples of how to incorporate these flags into a requirements.txt file are also in order. I'm having quite a bit of trouble figuring it out, despite the comments in that other thread about it. (The trouble may be compounded by the fact that I have more than one requirement in the file.) In fact, it may be worth having a separate documentation page addressing these flags and potential ways of working with them (the reasoning behind them, how to use them at the command line, how to use them in a requirements file, potential risks, and possibly suggestion of downgrading if old behavior is needed).

bladeoflight16 commented Jan 9, 2014

I think some examples of how to incorporate these flags into a requirements.txt file are also in order. I'm having quite a bit of trouble figuring it out, despite the comments in that other thread about it. (The trouble may be compounded by the fact that I have more than one requirement in the file.) In fact, it may be worth having a separate documentation page addressing these flags and potential ways of working with them (the reasoning behind them, how to use them at the command line, how to use them in a requirements file, potential risks, and possibly suggestion of downgrading if old behavior is needed).

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Jan 9, 2014

Contributor

I updated the 1.5 docs 4047b4b
If that's enough, let me know.

Contributor

qwcode commented Jan 9, 2014

I updated the 1.5 docs 4047b4b
If that's enough, let me know.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 10, 2014

Member

Fixed in #1457

Member

dstufft commented Jan 10, 2014

Fixed in #1457

@dstufft dstufft closed this Jan 10, 2014

@lsemel

This comment has been minimized.

Show comment
Hide comment
@lsemel

lsemel Jan 27, 2014

Is there an example of how to update an existing requirements.txt file? I have a long requirements filed pinned to specific versions of a large list of python packages, which now fails to install. What specifically do I need to add to get the versions I need to install installed? Looking at the docs file, it looks like I now have to go through each and every line of this file and find external packages for each package that fails, which is extremely time consuming. How do we get the exact old behavior?

lsemel commented Jan 27, 2014

Is there an example of how to update an existing requirements.txt file? I have a long requirements filed pinned to specific versions of a large list of python packages, which now fails to install. What specifically do I need to add to get the versions I need to install installed? Looking at the docs file, it looks like I now have to go through each and every line of this file and find external packages for each package that fails, which is extremely time consuming. How do we get the exact old behavior?

@bladeoflight16

This comment has been minimized.

Show comment
Hide comment
@bladeoflight16

bladeoflight16 Jan 29, 2014

The only way to actually get the old behavior is to use an old version of pip. As a result of your comment, I have opened #1518. I believe this addresses the difficulty you're experiencing. Feel free to comment about concerns I haven't addressed there.

bladeoflight16 commented Jan 29, 2014

The only way to actually get the old behavior is to use an old version of pip. As a result of your comment, I have opened #1518. I believe this addresses the difficulty you're experiencing. Feel free to comment about concerns I haven't addressed there.

@lsemel

This comment has been minimized.

Show comment
Hide comment
@lsemel

lsemel Jan 29, 2014

Thanks for opening #1518, @bladeoflight16. I've also noticed that older versions of packages are failing under pip 1.5. See http://stackoverflow.com/questions/21386880/cant-install-old-versions-with-pip-anymore for an example of where the current version of the package works and an older one that previously worked now fails. Does this mean that whenever a package version goes out of date, the requirements.txt has to be changed to allow external and unverified? That seems like a maintenance nightmare for any project with more than a handful of packages installed.

lsemel commented Jan 29, 2014

Thanks for opening #1518, @bladeoflight16. I've also noticed that older versions of packages are failing under pip 1.5. See http://stackoverflow.com/questions/21386880/cant-install-old-versions-with-pip-anymore for an example of where the current version of the package works and an older one that previously worked now fails. Does this mean that whenever a package version goes out of date, the requirements.txt has to be changed to allow external and unverified? That seems like a maintenance nightmare for any project with more than a handful of packages installed.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 29, 2014

Member

The requirement for --allow-external and/or --allow-unverified has nothing to do with the age or version of the package. It is entirely concerned with where it is hosted in relation to the index server.

Member

dstufft commented Jan 29, 2014

The requirement for --allow-external and/or --allow-unverified has nothing to do with the age or version of the package. It is entirely concerned with where it is hosted in relation to the index server.

@bladeoflight16

This comment has been minimized.

Show comment
Hide comment
@bladeoflight16

bladeoflight16 Jan 31, 2014

@lsemel To elaborate on dstufft's response, what you could be describing is that some old versions of a package are hosted externally and insecurely, whereas newer versions are hosted non-externally and securely. This would represent a decision by the maintainers of the project (likely in response to this change in pip): they decided to host newer versions in a location that will not trigger this warning, but they opted not to move older versions to the same location. In this scenario, unless the maintainers decide to move all versions of the package to a new location, old versions will continue to require these arguments, whereas versions from now on (not just the newest one) will not.

bladeoflight16 commented Jan 31, 2014

@lsemel To elaborate on dstufft's response, what you could be describing is that some old versions of a package are hosted externally and insecurely, whereas newer versions are hosted non-externally and securely. This would represent a decision by the maintainers of the project (likely in response to this change in pip): they decided to host newer versions in a location that will not trigger this warning, but they opted not to move older versions to the same location. In this scenario, unless the maintainers decide to move all versions of the package to a new location, old versions will continue to require these arguments, whereas versions from now on (not just the newest one) will not.

@exhuma

This comment has been minimized.

Show comment
Hide comment
@exhuma

exhuma Feb 6, 2014

I am running into this annoyance as well. We have an internal private Python repo where we push all our libraries and apps. Some applications have more than one requirement, so specifying --allow-external <something> is extremely annoying. I see the value of the security and I am reluctant to put the {}-all variants in there.

I would much rather white-list our entire private repo than do it manually for each package. Also, from our point of view, pypi is "external" and our own repo is "internal", yet it sees it as external... maybe --allow-non-pypi?.,.. but in the end that's only semantics.

exhuma commented Feb 6, 2014

I am running into this annoyance as well. We have an internal private Python repo where we push all our libraries and apps. Some applications have more than one requirement, so specifying --allow-external <something> is extremely annoying. I see the value of the security and I am reluctant to put the {}-all variants in there.

I would much rather white-list our entire private repo than do it manually for each package. Also, from our point of view, pypi is "external" and our own repo is "internal", yet it sees it as external... maybe --allow-non-pypi?.,.. but in the end that's only semantics.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Feb 6, 2014

Member

What are you using for your internal repo? The external check I'd supposed to only activate if the repo has opted in to it (as PyPI does) to make it work for internal repos automatically. Perhaps there is a bug turning it on anyways.

On Feb 6, 2014, at 3:40 AM, exhuma notifications@github.com wrote:

I am running into this annoyance as well. We have an internal private Python repo where we push all our libraries and apps. Some applications have more than one requirement, so specifying --allow-external is extremely annoying. I see the value of the security and I am reluctant to put the {}-all variants in there.

I would much rather white-list our entire private repo than do it manually for each package. Also, from our point of view, pypi is "external" and our own repo is "internal", yet it sees it as external... maybe --allow-non-pypi?.,.. but in the end that's only semantics.


Reply to this email directly or view it on GitHub.

Member

dstufft commented Feb 6, 2014

What are you using for your internal repo? The external check I'd supposed to only activate if the repo has opted in to it (as PyPI does) to make it work for internal repos automatically. Perhaps there is a bug turning it on anyways.

On Feb 6, 2014, at 3:40 AM, exhuma notifications@github.com wrote:

I am running into this annoyance as well. We have an internal private Python repo where we push all our libraries and apps. Some applications have more than one requirement, so specifying --allow-external is extremely annoying. I see the value of the security and I am reluctant to put the {}-all variants in there.

I would much rather white-list our entire private repo than do it manually for each package. Also, from our point of view, pypi is "external" and our own repo is "internal", yet it sees it as external... maybe --allow-non-pypi?.,.. but in the end that's only semantics.


Reply to this email directly or view it on GitHub.

@exhuma

This comment has been minimized.

Show comment
Hide comment
@exhuma

exhuma Feb 6, 2014

Thanks for the quick reply :)

It's just a simple apache web-listing (a remote folder exposed via httpd and +Indexes).

Following this issue, I also just read your blog post discussing requirements.txt vs setup.py. It was quite interesting! I managed to install my application using a requirements file. But it still is annoying to specify the "allow" flags for each dependency from the internal repo.

exhuma commented Feb 6, 2014

Thanks for the quick reply :)

It's just a simple apache web-listing (a remote folder exposed via httpd and +Indexes).

Following this issue, I also just read your blog post discussing requirements.txt vs setup.py. It was quite interesting! I managed to install my application using a requirements file. But it still is annoying to specify the "allow" flags for each dependency from the internal repo.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Feb 6, 2014

Member

Yea something is wrong it sounds like. You're pointing to it with --find-links? Can you show me the html pip is accessing? You can email it to donald@stufft.io if you don't want to publish it. Also can you tell me the exact command you're typing.

Member

dstufft commented Feb 6, 2014

Yea something is wrong it sounds like. You're pointing to it with --find-links? Can you show me the html pip is accessing? You can email it to donald@stufft.io if you don't want to publish it. Also can you tell me the exact command you're typing.

@exhuma

This comment has been minimized.

Show comment
Hide comment
@exhuma

exhuma Feb 6, 2014

I was actually using dependency_links inside setup.py. So the "old way" of doing things :)

The actual command to install the package was ./env/bin/pip install -e .

Given you post about the requirements file, I am considering re-thinking our deployment process. I understand the idea behind splitting abstract and concrete dependencies, but I dislike it so I avoided it until now.

The actual HTML output looks something like this (cut out some parts for brevity):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /pyrepo</title>
 </head>
 <body>
<h1>Index of /pyrepo</h1>
<table><tr><th><img src="/icons/blank.gif" alt="[ICO]"></th><th><a href="?C=N;O=D">Name</a></th><th><a href="?C=M;O=A">Last modified</a></th><th><a href="?C=S;O=A">Size</a></th><th><a href="?C=D;O=A">Description</a></th></tr><tr><th colspan="5"><hr></th></tr>
<tr><td valign="top"><img src="/icons/back.gif" alt="[DIR]"></td><td><a href="/">Parent Directory</a></td><td>&nbsp;</td><td align="right">  - </td><td>&nbsp;</td></tr>
[...]
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="auto_icms-1.7.tar.gz">auto_icms-1.7.tar.gz</a></td><td align="right">21-Jan-2014 14:28  </td><td align="right">2.4M</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.0.1.tar.gz">bitstream-1.0.1.tar.gz</a></td><td align="right">05-Nov-2012 12:06  </td><td align="right">3.3K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.0dev4.tar.gz">bitstream-1.0dev4.tar.gz</a></td><td align="right">25-Sep-2012 16:44  </td><td align="right">3.3K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.1.0.tar.gz">bitstream-1.1.0.tar.gz</a></td><td align="right">23-Nov-2012 14:24  </td><td align="right">3.4K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.2.0.tar.gz">bitstream-1.2.0.tar.gz</a></td><td align="right">26-Nov-2012 17:04  </td><td align="right">3.4K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.3.0.tar.gz">bitstream-1.3.0.tar.gz</a></td><td align="right">10-Jan-2013 10:01  </td><td align="right">3.5K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.4.0.tar.gz">bitstream-1.4.0.tar.gz</a></td><td align="right">21-Jan-2013 16:51  </td><td align="right">4.0K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.4.1.tar.gz">bitstream-1.4.1.tar.gz</a></td><td align="right">22-Mar-2013 15:29  </td><td align="right">3.9K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.5.0.tar.gz">bitstream-1.5.0.tar.gz</a></td><td align="right">17-Apr-2013 16:06  </td><td align="right">5.4K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-2.0.0.tar.gz">bitstream-2.0.0.tar.gz</a></td><td align="right">17-May-2013 14:07  </td><td align="right">5.5K</td><td>&nbsp;</td></tr>
[...]
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.2.1.tar.gz">ipbase-1.2.1.tar.gz</a></td><td align="right">27-Nov-2013 17:10  </td><td align="right"> 40K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.2.2.tar.gz">ipbase-1.2.2.tar.gz</a></td><td align="right">27-Dec-2013 16:39  </td><td align="right"> 40K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.3.0.tar.gz">ipbase-1.3.0.tar.gz</a></td><td align="right">17-Jan-2014 11:53  </td><td align="right"> 46K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.3.1.tar.gz">ipbase-1.3.1.tar.gz</a></td><td align="right">04-Feb-2014 14:42  </td><td align="right"> 43K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.4.0.tar.gz">ipbase-1.4.0.tar.gz</a></td><td align="right">05-Feb-2014 16:40  </td><td align="right"> 52K</td><td>&nbsp;</td></tr>
[...]
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="toolbox-2.0.tar.gz">toolbox-2.0.tar.gz</a></td><td align="right">24-Oct-2013 16:43  </td><td align="right">145K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="toolbox-2.1.tar.gz">toolbox-2.1.tar.gz</a></td><td align="right">15-Nov-2013 11:44  </td><td align="right">158K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="toolbox-3.0.tar.gz">toolbox-3.0.tar.gz</a></td><td align="right">21-Nov-2013 11:35  </td><td align="right">158K</td><td>&nbsp;</td></tr>
<tr><th colspan="5"><hr></th></tr>
</table>
</body></html>

exhuma commented Feb 6, 2014

I was actually using dependency_links inside setup.py. So the "old way" of doing things :)

The actual command to install the package was ./env/bin/pip install -e .

Given you post about the requirements file, I am considering re-thinking our deployment process. I understand the idea behind splitting abstract and concrete dependencies, but I dislike it so I avoided it until now.

The actual HTML output looks something like this (cut out some parts for brevity):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /pyrepo</title>
 </head>
 <body>
<h1>Index of /pyrepo</h1>
<table><tr><th><img src="/icons/blank.gif" alt="[ICO]"></th><th><a href="?C=N;O=D">Name</a></th><th><a href="?C=M;O=A">Last modified</a></th><th><a href="?C=S;O=A">Size</a></th><th><a href="?C=D;O=A">Description</a></th></tr><tr><th colspan="5"><hr></th></tr>
<tr><td valign="top"><img src="/icons/back.gif" alt="[DIR]"></td><td><a href="/">Parent Directory</a></td><td>&nbsp;</td><td align="right">  - </td><td>&nbsp;</td></tr>
[...]
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="auto_icms-1.7.tar.gz">auto_icms-1.7.tar.gz</a></td><td align="right">21-Jan-2014 14:28  </td><td align="right">2.4M</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.0.1.tar.gz">bitstream-1.0.1.tar.gz</a></td><td align="right">05-Nov-2012 12:06  </td><td align="right">3.3K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.0dev4.tar.gz">bitstream-1.0dev4.tar.gz</a></td><td align="right">25-Sep-2012 16:44  </td><td align="right">3.3K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.1.0.tar.gz">bitstream-1.1.0.tar.gz</a></td><td align="right">23-Nov-2012 14:24  </td><td align="right">3.4K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.2.0.tar.gz">bitstream-1.2.0.tar.gz</a></td><td align="right">26-Nov-2012 17:04  </td><td align="right">3.4K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.3.0.tar.gz">bitstream-1.3.0.tar.gz</a></td><td align="right">10-Jan-2013 10:01  </td><td align="right">3.5K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.4.0.tar.gz">bitstream-1.4.0.tar.gz</a></td><td align="right">21-Jan-2013 16:51  </td><td align="right">4.0K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.4.1.tar.gz">bitstream-1.4.1.tar.gz</a></td><td align="right">22-Mar-2013 15:29  </td><td align="right">3.9K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-1.5.0.tar.gz">bitstream-1.5.0.tar.gz</a></td><td align="right">17-Apr-2013 16:06  </td><td align="right">5.4K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="bitstream-2.0.0.tar.gz">bitstream-2.0.0.tar.gz</a></td><td align="right">17-May-2013 14:07  </td><td align="right">5.5K</td><td>&nbsp;</td></tr>
[...]
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.2.1.tar.gz">ipbase-1.2.1.tar.gz</a></td><td align="right">27-Nov-2013 17:10  </td><td align="right"> 40K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.2.2.tar.gz">ipbase-1.2.2.tar.gz</a></td><td align="right">27-Dec-2013 16:39  </td><td align="right"> 40K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.3.0.tar.gz">ipbase-1.3.0.tar.gz</a></td><td align="right">17-Jan-2014 11:53  </td><td align="right"> 46K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.3.1.tar.gz">ipbase-1.3.1.tar.gz</a></td><td align="right">04-Feb-2014 14:42  </td><td align="right"> 43K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="ipbase-1.4.0.tar.gz">ipbase-1.4.0.tar.gz</a></td><td align="right">05-Feb-2014 16:40  </td><td align="right"> 52K</td><td>&nbsp;</td></tr>
[...]
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="toolbox-2.0.tar.gz">toolbox-2.0.tar.gz</a></td><td align="right">24-Oct-2013 16:43  </td><td align="right">145K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="toolbox-2.1.tar.gz">toolbox-2.1.tar.gz</a></td><td align="right">15-Nov-2013 11:44  </td><td align="right">158K</td><td>&nbsp;</td></tr>
<tr><td valign="top"><img src="/icons/compressed.gif" alt="[   ]"></td><td><a href="toolbox-3.0.tar.gz">toolbox-3.0.tar.gz</a></td><td align="right">21-Nov-2013 11:35  </td><td align="right">158K</td><td>&nbsp;</td></tr>
<tr><th colspan="5"><hr></th></tr>
</table>
</body></html>
@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Feb 6, 2014

Member

If you have a simple pypi-ish internal mirror, you can use pip install --index-url=http://my.lan/pyrepo/ <package> or pip install --no-index --find-links=http://my.lan/pyrepo/ <package>

Then no need for dependency links.

Member

Ivoz commented Feb 6, 2014

If you have a simple pypi-ish internal mirror, you can use pip install --index-url=http://my.lan/pyrepo/ <package> or pip install --no-index --find-links=http://my.lan/pyrepo/ <package>

Then no need for dependency links.

@exhuma

This comment has been minimized.

Show comment
Hide comment
@exhuma

exhuma Feb 6, 2014

@Ivoz Agreed. This is also as far as I can remember the process used in our deployment scripts. I only happened to fall into this security issue, as I ran a manual installation on another host for testing.

Our development process (as currently documented) still uses a setup.py with dependency_links simply because it's easier (as you only have to maintain one list of dependencies) and it works for us.

Once pip 1.4 hits our machines, we'll have to update our process, and I just want to get my facts straight before this happens.

It's a lazyness thing... typing ./env/bin/pip install -e . is way easier that ./env/bin/pip install -e --find-links=http://my.lan/pyrepo/ . :) Maybe I'll just opt in for something like fab develop which does the right thing behind the scenes.

exhuma commented Feb 6, 2014

@Ivoz Agreed. This is also as far as I can remember the process used in our deployment scripts. I only happened to fall into this security issue, as I ran a manual installation on another host for testing.

Our development process (as currently documented) still uses a setup.py with dependency_links simply because it's easier (as you only have to maintain one list of dependencies) and it works for us.

Once pip 1.4 hits our machines, we'll have to update our process, and I just want to get my facts straight before this happens.

It's a lazyness thing... typing ./env/bin/pip install -e . is way easier that ./env/bin/pip install -e --find-links=http://my.lan/pyrepo/ . :) Maybe I'll just opt in for something like fab develop which does the right thing behind the scenes.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Feb 6, 2014

Member

I think there's a problem with dependency links and external detection. I'm traveling at the moment but I plan on taking a look at this this weekend and seeing what I can figure out. External url stuff should only take effect when you're installing from a repo that opts into it. So unless you've added the metatag, which it doesn't look like you have, this is a legit bug.

I don't have the greatest editing environment right now, can you split this out into a new bug and CC me in it?

Member

dstufft commented Feb 6, 2014

I think there's a problem with dependency links and external detection. I'm traveling at the moment but I plan on taking a look at this this weekend and seeing what I can figure out. External url stuff should only take effect when you're installing from a repo that opts into it. So unless you've added the metatag, which it doesn't look like you have, this is a legit bug.

I don't have the greatest editing environment right now, can you split this out into a new bug and CC me in it?

@exhuma

This comment has been minimized.

Show comment
Hide comment
@exhuma

exhuma Feb 6, 2014

@dstufft done. I hope the message is not overly vague... It's also not something of high importance to me. It will only impact our development environment when pip 1.5 hits our dev boxes which is not yet the case. Also, deployment scripts are fine too. So there's no immediate hurry.

exhuma commented Feb 6, 2014

@dstufft done. I hope the message is not overly vague... It's also not something of high importance to me. It will only impact our development environment when pip 1.5 hits our dev boxes which is not yet the case. Also, deployment scripts are fine too. So there's no immediate hurry.

@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Feb 6, 2014

Member

@exhuma note, you can also specify in a ~/.pypirc file an alternate index to use, or alternatively in an environment variable (e.g PIP_FIND_LINKS) so on a command line or in many scripts you do not need to type these over and over.

see http://www.pip-installer.org/en/latest/configuration.html#configuration

You can also specify an alternative index in a requirements.txt.

Member

Ivoz commented Feb 6, 2014

@exhuma note, you can also specify in a ~/.pypirc file an alternate index to use, or alternatively in an environment variable (e.g PIP_FIND_LINKS) so on a command line or in many scripts you do not need to type these over and over.

see http://www.pip-installer.org/en/latest/configuration.html#configuration

You can also specify an alternative index in a requirements.txt.

ryanfobel pushed a commit to ryanfobel/microdrop that referenced this issue Feb 18, 2014

Remove dependency_links...
Remove `dependency_links` since they cause issues with recent versions
of `pip`, which require the specification of [`allow-external` and
`allow-unverified`][1] for install to work properly for this package.
In an effort to simplify things for the time-being, we simply list the
dependencies and assume that they are installed, or available through
PyPi.

[1]: pypa/pip#1423
@rbpasker

This comment has been minimized.

Show comment
Hide comment
@rbpasker

rbpasker Mar 5, 2014

TL;DR: if you get errors for, say, 'egenix-mx-base', change your requirements.txt as follows:

old:

    egenix-mx-base==3.2.6

new:

    --allow-unverified egenix-mx-base
    egenix-mx-base==3.2.6

note that version id is not specified in the --allow-unverified line

rbpasker commented Mar 5, 2014

TL;DR: if you get errors for, say, 'egenix-mx-base', change your requirements.txt as follows:

old:

    egenix-mx-base==3.2.6

new:

    --allow-unverified egenix-mx-base
    egenix-mx-base==3.2.6

note that version id is not specified in the --allow-unverified line

@lsemel

This comment has been minimized.

Show comment
Hide comment
@lsemel

lsemel Mar 5, 2014

Is there any way to avoid repeating the package name for each and every
line in the requirements.txt that fails?


Lee Semel
leesemel.com - linkedin http://www.linkedin.com/in/leesemel -
twitterhttp://twitter.com/#%21/semel

On Wed, Mar 5, 2014 at 4:03 PM, bob pasker notifications@github.com wrote:

TL;DR: if you get errors for, say, 'egenix-mx-base', change your
requirements.txt as follows:

old:

egenix-mx-base==3.2.6

new:

--allow-unverified egenix-mx-base
egenix-mx-base==3.2.6

note that version id is not specified in the --allow-unverified line

Reply to this email directly or view it on GitHubhttps://github.com//issues/1423#issuecomment-36793071
.

lsemel commented Mar 5, 2014

Is there any way to avoid repeating the package name for each and every
line in the requirements.txt that fails?


Lee Semel
leesemel.com - linkedin http://www.linkedin.com/in/leesemel -
twitterhttp://twitter.com/#%21/semel

On Wed, Mar 5, 2014 at 4:03 PM, bob pasker notifications@github.com wrote:

TL;DR: if you get errors for, say, 'egenix-mx-base', change your
requirements.txt as follows:

old:

egenix-mx-base==3.2.6

new:

--allow-unverified egenix-mx-base
egenix-mx-base==3.2.6

note that version id is not specified in the --allow-unverified line

Reply to this email directly or view it on GitHubhttps://github.com//issues/1423#issuecomment-36793071
.

@mjallday

This comment has been minimized.

Show comment
Hide comment
@mjallday

mjallday Jun 9, 2014

can someone please update this with how to solve this issue when specifying dependencies in setup.py?

moving to requirements.txt does not seem like a good solution since I don't then understand how to specify dependencies for anything we have that depends on the package that moves to requirements.txt.

googling this issue continues to bring up this github thread which only discusses the ramifications, not the solution (for me anyway).

mjallday commented Jun 9, 2014

can someone please update this with how to solve this issue when specifying dependencies in setup.py?

moving to requirements.txt does not seem like a good solution since I don't then understand how to specify dependencies for anything we have that depends on the package that moves to requirements.txt.

googling this issue continues to bring up this github thread which only discusses the ramifications, not the solution (for me anyway).

@powellc

This comment has been minimized.

Show comment
Hide comment
@powellc

powellc Jun 27, 2014

@mjallday I second your concern. I'm still not sure how to get an unverified package in a requirements flie. I've added --allow-all-external to my requirements install command (pip install --allow-all-external -r requirements.txt) but it still hangs on unverified packages.

I'm non-plussed about this change to pip and while I appreciate the necessity of protecting us from malicious packages, there has to be a way to implement this that is not nearly so awkward.

powellc commented Jun 27, 2014

@mjallday I second your concern. I'm still not sure how to get an unverified package in a requirements flie. I've added --allow-all-external to my requirements install command (pip install --allow-all-external -r requirements.txt) but it still hangs on unverified packages.

I'm non-plussed about this change to pip and while I appreciate the necessity of protecting us from malicious packages, there has to be a way to implement this that is not nearly so awkward.

@powellc

This comment has been minimized.

Show comment
Hide comment
@powellc

powellc Jun 27, 2014

I would also add that in the interface, using "==" for package versions and "=" for the packages that are allowed unverified is confusing and has led to more than a few bugs on my end.

All in all I would love for this whole external and unverified packages scheme to be completely rethought. If I can find the time I'll try to submit a pull request.

powellc commented Jun 27, 2014

I would also add that in the interface, using "==" for package versions and "=" for the packages that are allowed unverified is confusing and has led to more than a few bugs on my end.

All in all I would love for this whole external and unverified packages scheme to be completely rethought. If I can find the time I'll try to submit a pull request.

@erikjms

This comment has been minimized.

Show comment
Hide comment
@erikjms

erikjms Aug 10, 2014

A voice from a casual python user (I never inhale):

And so probably I have not googled sufficiently to understand all of what is going on with pip 1.5.6, but I am not a sysadmin (excepting this one single sys here), and I don't install lots of different environments. Most often I install packages on an as-needed basis so that I can run various free/open-source sound and graphics applications that happen to be written in python. My needs are convenience and clarity so that I can go quickly from installing an application and/or its dependencies to using it. Virtually every python package I have needed ever has been hosted on pypi. This has not changed.

This is my experience in a nutshell:

Since updating pip, what used to look like this
$ pip install wxpython

now must look like this to work
$ pip install --allow-external wxpython --allow-unverified wxpython wxpython==2.9.1.1

edit: omygod. that did not actually work. I really need to replace that dark red in my terminal profile with something a little brighter. I will figure this out, but do you see what I am getting at?

When this did not work:
$ pip install --allow-external wxpython --allow-unverified wxpython

I found myself reading this thread because I was completely exasperated. The pip documentation online does not hint at the necessity of naming a single package three times for relatively simple installs like this one. Last week trying to use pip I think I gave up and decided to go do something else--I left no notes on how to deal with the sinking feeling that I recognized immediately on reading "Use --allow-external". Tonight though I had the energy to google.

Obviously I have copied and pasted the working install command in my sysadmin cheat notepad for future reference, but, I don't know. Maybe my opinion carries no weight since I am but a dilettante when it comes to programming, but I can't be the only non-coder coder out here scratching my head.

erikjms commented Aug 10, 2014

A voice from a casual python user (I never inhale):

And so probably I have not googled sufficiently to understand all of what is going on with pip 1.5.6, but I am not a sysadmin (excepting this one single sys here), and I don't install lots of different environments. Most often I install packages on an as-needed basis so that I can run various free/open-source sound and graphics applications that happen to be written in python. My needs are convenience and clarity so that I can go quickly from installing an application and/or its dependencies to using it. Virtually every python package I have needed ever has been hosted on pypi. This has not changed.

This is my experience in a nutshell:

Since updating pip, what used to look like this
$ pip install wxpython

now must look like this to work
$ pip install --allow-external wxpython --allow-unverified wxpython wxpython==2.9.1.1

edit: omygod. that did not actually work. I really need to replace that dark red in my terminal profile with something a little brighter. I will figure this out, but do you see what I am getting at?

When this did not work:
$ pip install --allow-external wxpython --allow-unverified wxpython

I found myself reading this thread because I was completely exasperated. The pip documentation online does not hint at the necessity of naming a single package three times for relatively simple installs like this one. Last week trying to use pip I think I gave up and decided to go do something else--I left no notes on how to deal with the sinking feeling that I recognized immediately on reading "Use --allow-external". Tonight though I had the energy to google.

Obviously I have copied and pasted the working install command in my sysadmin cheat notepad for future reference, but, I don't know. Maybe my opinion carries no weight since I am but a dilettante when it comes to programming, but I can't be the only non-coder coder out here scratching my head.

@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Aug 11, 2014

Member

@erikjms I think the pip maintainers can agree although there was a clear aim in introducing these flags, the User Experience of the implementation wasn't thought through enough at the time and ended up being unnecessarily confusing. @dstufft @qwcode @pfmoore we should definitely discuss before 1.6 to make sure this has been improved.

Member

Ivoz commented Aug 11, 2014

@erikjms I think the pip maintainers can agree although there was a clear aim in introducing these flags, the User Experience of the implementation wasn't thought through enough at the time and ended up being unnecessarily confusing. @dstufft @qwcode @pfmoore we should definitely discuss before 1.6 to make sure this has been improved.

@bladeoflight16

This comment has been minimized.

Show comment
Hide comment
@bladeoflight16

bladeoflight16 Aug 14, 2014

@Ivoz Thank you so much. I think this is all we were really asking for.

bladeoflight16 commented Aug 14, 2014

@Ivoz Thank you so much. I think this is all we were really asking for.

@ogrotten

This comment has been minimized.

Show comment
Hide comment
@ogrotten

ogrotten Jan 24, 2015

So what's the currently recommended command to install an external pkg? $ pip install --allow-all-external --allow-unverified mysql-connector-python didn't work, nor does any of it's simpler derivations.

edit: nevermind. have to have the name twice at the end.

$ pip install --allow-all-external --allow-unverified mysql-connector-python mysql-connector-python

To be perfectly honest, and not to hash over all the same arguments above, I wouldn't have a problem with this syntax if it were sensibly documented.

ogrotten commented Jan 24, 2015

So what's the currently recommended command to install an external pkg? $ pip install --allow-all-external --allow-unverified mysql-connector-python didn't work, nor does any of it's simpler derivations.

edit: nevermind. have to have the name twice at the end.

$ pip install --allow-all-external --allow-unverified mysql-connector-python mysql-connector-python

To be perfectly honest, and not to hash over all the same arguments above, I wouldn't have a problem with this syntax if it were sensibly documented.

@xavfernandez

This comment has been minimized.

Show comment
Hide comment
@xavfernandez

xavfernandez Jan 24, 2015

Contributor

allow-unverified option needs a package
You must do:

$ pip install --allow-all-external --allow-unverified mysql-connector-python mysql-connector-python
Contributor

xavfernandez commented Jan 24, 2015

allow-unverified option needs a package
You must do:

$ pip install --allow-all-external --allow-unverified mysql-connector-python mysql-connector-python
@macropin

This comment has been minimized.

Show comment
Hide comment
@macropin

macropin Jul 14, 2015

I'm not sure why this was closed. This title of this ticket is still valid.

macropin commented Jul 14, 2015

I'm not sure why this was closed. This title of this ticket is still valid.

@powellc

This comment has been minimized.

Show comment
Hide comment
@powellc

powellc Jul 14, 2015

I think the instructions were supposedly clarified, but I would agree @macropin

powellc commented Jul 14, 2015

I think the instructions were supposedly clarified, but I would agree @macropin

@macropin

This comment has been minimized.

Show comment
Hide comment
@macropin

macropin Jul 14, 2015

@powellc I think the principle of least astonishment needs to be applied here...

A simple pip install --unsafe <pkg_name> should suffice.

macropin commented Jul 14, 2015

@powellc I think the principle of least astonishment needs to be applied here...

A simple pip install --unsafe <pkg_name> should suffice.

@isbm

This comment has been minimized.

Show comment
Hide comment
@isbm

isbm Jul 16, 2015

Holy cow, I am still struggling install that damn apt that pip continues skipping. Maybe I shall buy a tambourine instead... Hello to those, who designed this! 😠

isbm commented Jul 16, 2015

Holy cow, I am still struggling install that damn apt that pip continues skipping. Maybe I shall buy a tambourine instead... Hello to those, who designed this! 😠

@bladeoflight16

This comment has been minimized.

Show comment
Hide comment
@bladeoflight16

bladeoflight16 Jul 16, 2015

@isbm Pretty sure that has nothing to do with pip. This StackOverflow question comes up fairly early in the Google results. If you have more difficulties, this really isn't the appropriate place to address them. Try one of the Stack Exchange sites.

@macropin It was closed because a change was made so that --allow-unverified now implies --allow-external. That said, I do find your suggestion more intuitive, but it's not as bad as it used to be.

bladeoflight16 commented Jul 16, 2015

@isbm Pretty sure that has nothing to do with pip. This StackOverflow question comes up fairly early in the Google results. If you have more difficulties, this really isn't the appropriate place to address them. Try one of the Stack Exchange sites.

@macropin It was closed because a change was made so that --allow-unverified now implies --allow-external. That said, I do find your suggestion more intuitive, but it's not as bad as it used to be.

@ut-adamc

This comment has been minimized.

Show comment
Hide comment
@ut-adamc

ut-adamc commented Aug 5, 2015

@macropin: I agree.

@zx1986

This comment has been minimized.

Show comment
Hide comment
@zx1986

zx1986 Nov 22, 2015

pip install --allow-all-external --allow-unverified elementtree elementtree
works for me too ....

zx1986 commented Nov 22, 2015

pip install --allow-all-external --allow-unverified elementtree elementtree
works for me too ....

@anirudhp2014

This comment has been minimized.

Show comment
Hide comment
@anirudhp2014

anirudhp2014 Dec 9, 2015

--allow-external never worker for me .

anirudhp2014 commented Dec 9, 2015

--allow-external never worker for me .

@xavfernandez

This comment has been minimized.

Show comment
Hide comment
@xavfernandez

xavfernandez Dec 13, 2015

Contributor

They'll both be deprecated in a few weeks, as per http://legacy.python.org/dev/peps/pep-0470/ .

Contributor

xavfernandez commented Dec 13, 2015

They'll both be deprecated in a few weeks, as per http://legacy.python.org/dev/peps/pep-0470/ .

kdeldycke added a commit to kdeldycke/dotfiles that referenced this issue Jan 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment