The common approach to get a unique collection of items is to use a set
. Sets are unordered collections of distinct objects. To create a set from any iterable, you can simply pass it to the built-in set()
function. If you later need a real list again, you can similarly pass the set to the list()
function.
The following example should cover whatever you are trying to do:
>>> t = [1, 2, 3, 1, 2, 5, 6, 7, 8]
>>> t
[1, 2, 3, 1, 2, 5, 6, 7, 8]
>>> list(set(t))
[1, 2, 3, 5, 6, 7, 8]
>>> s = [1, 2, 3]
>>> list(set(t) - set(s))
[8, 5, 6, 7]
As you can see from the example result, the original order is not maintained. As mentioned above, sets themselves are unordered collections, so the order is lost. When converting a set back to a list, an arbitrary order is created.
Maintaining order
If order is important to you, then you will have to use a different mechanism. A very common solution for this is to rely on OrderedDict
to keep the order of keys during insertion:
>>> from collections import OrderedDict
>>> list(OrderedDict.fromkeys(t))
[1, 2, 3, 5, 6, 7, 8]
Starting with Python 3.7, the built-in dictionary is guaranteed to maintain the insertion order as well, so you can also use that directly if you are on Python 3.7 or later (or CPython 3.6):
>>> list(dict.fromkeys(t))
[1, 2, 3, 5, 6, 7, 8]
Note that this may have some overhead of creating a dictionary first, and then creating a list from it. If you don’t actually need to preserve the order, you’re often better off using a set, especially because it gives you a lot more operations to work with. Check out this question for more details and alternative ways to preserve the order when removing duplicates.
Finally note that both the set
as well as the OrderedDict
/dict
solutions require your items to be hashable. This usually means that they have to be immutable. If you have to deal with items that are not hashable (e.g. list objects), then you will have to use a slow approach in which you will basically have to compare every item with every other item in a nested loop.
The problem seems to be that --download-cache
can only be used to specify the cache for downloading, not for installing. Therefore pip
is still looking at /usr/local/myapp/.env/build/Django
instead of /usr/local/pip/cache
. Have you tried moving
pip install --upgrade --timeout=120 --use-mirrors --no-install --download-cache /usr/local/pip/cache -r pip-requirements.txt
to after the creation of virtualenv
? I wonder if that would help.
You may also want to try to export PIP_DOWNLOAD_CACHE
and see if it works without using --download-cache
.
Here is what I find that works:
pip install --no-install --use-mirrors --download=/DIRNAME PKGNAME
pip install --find-links=file:///DIRNAME --no-index --index-url=file:///dev/null PKGNAME
Now, actually, here is the tool for I would use instead of all the above and it solves all of the problems much more elegantly and reliably: pip2pi by David Wolever.
From the docs:
pip2pi builds a PyPI-compatible package repository from pip requirements
pip2pi
allows you to create your own PyPI index by using two simple commands:
To mirror a package and all of its requirements, use pip2tgz
:
$ cd /tmp/; mkdir package/
$ pip2tgz packages/ httpie==0.2
...
$ ls packages/
Pygments-1.5.tar.gz
httpie-0.2.0.tar.gz
requests-0.14.0.tar.gz
To build a package index from the previous directory:
$ ls packages/
bar-0.8.tar.gz
baz-0.3.tar.gz
foo-1.2.tar.gz
$ dir2pi packages/
$ find packages/
/httpie-0.2.0.tar.gz
/Pygments-1.5.tar.gz
/requests-0.14.0.tar.gz
/simple
/simple/httpie
/simple/httpie/httpie-0.2.0.tar.gz
/simple/Pygments
/simple/Pygments/Pygments-1.5.tar.gz
/simple/requests
/simple/requests/requests-0.14.0.tar.gz
To install from the index you built in step 2., you can simply use:
pip install --index-url=file:///tmp/packages/simple/ httpie==0.2
Bonus: you can even mirror your own index to a remote host with pip2pi
.
Best Answer
If using pip 6.0 or newer, try adding the
--no-cache-dir
option (source).If using pip older than pip 6.0, upgrade it with
pip install -U pip
.