| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
--HG--
extra : amend_source : 9576c3d20e8d3bcb3b951cd2f588e782f885ebe6
|
| |
| |
| |
| |
| |
| |
| |
| | |
such sub directories.
--HG--
branch : develop
extra : rebase_source : 2b3326fe668e880b351b0d5f388472239d915d58
|
| |
| |
| |
| |
| |
| | |
--HG--
branch : develop
extra : rebase_source : 571dac8142fc43b54bcd0302598766b0bb9e13ff
|
| |
| |
| |
| |
| | |
--HG--
extra : amend_source : fa41c3fb787b667f703f67a52aed7a2958e615b4
|
| | |
|
| |
| |
| |
| | |
67bdf3a726962 where only the last dat would be written.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
|/ / |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
--HG--
extra : rebase_source : beb6c57dfd500432304518b9d313d1a98e2614b9
|
| | |
| | |
| | |
| | |
| | | |
--HG--
extra : rebase_source : 04b4807ccc7bf95d87797716f5d3488d420fa692
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
PyPy's zipimport._zip_directory_cache implementation does not support direct
item assignment, thus breaking our attempts at silently updating the cached zip
archive directory information behind the scene. As a workaround, when using
PyPy, we fall back to simply clearing the stale cached information.
--HG--
extra : amend_source : 991e30244754d8fac042da56ac4cf0ad1a0f50d5
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is an extra safety measure to avoid someone holding a reference to this
cached data and using its content even after we know that the underlying zip
archive has been removed and possibly even replaced.
Change suggested by PJ Eby (pje on BitBucket) in a setuptools pull request #51
comment:
https://bitbucket.org/pypa/setuptools/pull-request/51/diff#comment-2018183
--HG--
extra : rebase_source : 6de2309bc7446647749cfe78ab00e0230a07f92f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
_update_zipimporter_cache() extracted from _uncache() &
_replace_zip_directory_cache_data().
Code cleanup done in preparation for adding a bit more detailed cache item
clearing logic, so that would not require adding a separate function with yet
more code duplication.
--HG--
extra : rebase_source : e2e956e042c7cbfabe2c31ecc58a4f76c91f40aa
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Extracted code for collecting a list of zipimporter cache entries related to a
given path into _collect_zipimporter_cache_entries().
--HG--
extra : rebase_source : 54ab881d794f95467e811511433a2cd31595339e
|
| | |
| | |
| | |
| | |
| | | |
--HG--
extra : rebase_source : c8c77d96880275e34c1580991c2d70486b6d0e00
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
pypy uses a custom zipimport._zip_directory_cache implementation class that
does not support the complete dict interface, e.g. it does not support the
dict.pop() method.
For more detailed information see the following links:
https://bitbucket.org/pypa/setuptools/issue/202/more-robust-zipimporter-cache-invalidation#comment-10495960
https://bitbucket.org/pypy/pypy/src/dd07756a34a41f674c0cacfbc8ae1d4cc9ea2ae4/pypy/module/zipimport/interp_zipimport.py#cl-99
--HG--
extra : rebase_source : 95cff7946455f0a4422d97eecab11164a9ddef10
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Although the original problematic use case when we are replacing a zipped egg
distribution with another zipped egg distribution is now cleanly handled by
fixing all existing zipimport.zipimporter loaders, this fix is still valid for
cases when replacing a distribution with a non-zipped egg folder.
--HG--
extra : source : efd6a8b82bafdbcfad1971b7e0f470e19191be1a
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When replacing a zipped egg distribution with a different zipped egg, we make
all existing zipimport.zipimporter loaders valid again instead of having to go
hunting them down one by one. This is done by updating their shared zip
directory information cache - zipimport._zip_directory_cache.
Related to the following project issues:
#169 - http://bitbucket.org/pypa/setuptools/issue/168
#202 - http://bitbucket.org/pypa/setuptools/issue/202
--HG--
extra : source : b60beb7792252a39f61d7fc0f58aa04c03ddaba2
|
| | |
| | |
| | |
| | |
| | |
| | | |
--HG--
rename : setuptools/script template (dev).py => setuptools/script (dev).tmpl
rename : setuptools/script template.py => setuptools/script.tmpl
|
| | |
| | |
| | |
| | | |
to be syntactically incorrect (prior to substitution).
|
| | | |
|
|/ / |
|
|/
|
|
|
|
|
| |
https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation
--HG--
extra : source : 182f68beacf5e436609fb7d1064a18279cbbd24a
|
| |
|
|
|
|
| |
newline to each line of the file, not just intervening lines.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
--HG--
extra : source : 199c917b8a0be209144878872269c3bd08936d6a
|
|
|
|
|
|
|
|
|
|
| |
*Since py2.5 has been dropped, we can use future imports to
make use of with statements.
*End goal was to always decode to utf-8 in write_file on 307
--HG--
extra : rebase_source : 502ea7128f4e3b843b16c6d64d6d0b2ac56ce87d
|
|
|
|
| |
added.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
on it when building the manifest. Ref #193
|
| |
|