[issue21417] Compression level for zipfile
Changes by Florian Berger : -- nosy: +fberger ___ Python tracker <http://bugs.python.org/issue21417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17274] distutils silently omits relative symlinks
New submission from Florian Berger:
This issue is related to #12585, #15205 and #8876.
In `distutils/archive_util.py`, in `make_zipfile()`, the code
for dirpath, dirnames, filenames in os.walk(base_dir):
for name in filenames:
path = os.path.normpath(os.path.join(dirpath, name))
if os.path.isfile(path):
zip.write(path, path)
log.info("adding '%s'" % path)
will silently omit relative symlinks from the archive.
Relative symlinks (`file.dat -> ../../../real_file.dat`) will become invalid
when copied as-is into the package directory before compressing.
`os.path.isfile(path)` will evaluate to `False` in this case.
That is a critical condition, as the file has explicitly been specified for
inclusion, but the package author is never warned about the fact, rendering the
distributed package defunct in worst case.
Actual behaviour: relative symlinks are silently ignored.
Expected behaviour: any file that, for whatever reason, can not be included in
the distribution archive should be warned about.
As hinted at in #15205, this might be fixed in `distutils2` / `packaging` in
case it always dereferences and copies files.
This issue could be fixed without breaking behaviour if no Exception is raised,
but a warning is printed.
With `packaging` available in Python 3.3, this report also serves as
documentation of the problem for legacy Python programmers searching the web.
Thanks for considering.
--
assignee: eric.araujo
components: Distutils
messages: 182658
nosy: eric.araujo, fberger, tarek
priority: normal
severity: normal
status: open
title: distutils silently omits relative symlinks
versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue17274>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5998] Add __bool__ to threading.Event and multiprocessing.Event
Florian Berger added the comment: Voting for re-opening. I am currently porting a non-threaded function for use within a threaded application. If threading.Event had __bool__, it would be a drop-in replacement for simple True/False flags that can not be used in multithreaded code. To me, it is actually surprising that I can not do tests like "if event: ...". IMHO, "if event.is_set(): ..." is unnecessarily complicated, especially with the documentation speaking of a true/false flag all the time. I will subclass threading.Event now and add __bool__, but I don't feel this is a nice solution. -- nosy: +fberger ___ Python tracker <http://bugs.python.org/issue5998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12585] distutils dereferences symlinks for zip but not for bztar/gztar target
Florian Berger added the comment: > Okay. Adding the easy keyword to lure contributors. Thanks. > I wonder if there is something to fix at all; tar is a smart container > format whereas zip is simpler, so I would not be surprised if the > source of the difference is just that zip cannot contain links. In my mind, that is no excuse for inconsistent behaviour on part of the wrapper. If the *user* (i.e. package creator) had any choice of storing symlinks "as is" or the file linked, I would agree; but there is no option, no parameter, in fact not even a hint at the behaviour. On the contrary, the *wrapper* (i.e. distutils) does have a choice of derefering symlinks in a tar file or not. So, from my point of view: surprises == bad, options/parameters == good, transparent consitency == best. P.S. "Explicit is better than implicit" may also apply here. ;-) -- ___ Python tracker <http://bugs.python.org/issue12585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12585] distutils dereferences symlinks for zip but not for bztar/gztar target
Florian Berger added the comment: Hi, thanks for the reply. I see your point with the legacy distutils. > I hope that this explanation will let you see why I’m reluctant to > change distutils: we don’t know what code we will break if we improve > symlink handling. So, do you think adding a warning about symlink > handling issues in the docs would be enough? Given the constraints, yes, it would be good to have that warning in the docs. Even better would be a runtime hint like Notice: gztar target will preserve symbolic links. or Notice: zip target will dereference symbolic links. > For distutils2 however, compatibility concerns do not apply yet, > so we’re free to fix and document symlink handling. That would be very welcome. I am afraid I will not be able to contribute code anytime soon, but it would be great if the regular developers could keep an eye on this inconsistency. -- ___ Python tracker <http://bugs.python.org/issue12585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12585] distutils dereferences symlinks for zip but not for bztar/gztar target
New submission from Florian Berger :
When creating a source distribution, formats=zip will dereference symbolic
links while formats=bztar,gztar will not.
Example:
$ ls -l
drwxr-xr-x 3 4096 19. Jul 15:44 dist
-rw-r--r-- 1 53 19. Jul 15:15 foo.py
-rw-r--r-- 1 42 19. Jul 15:39 MANIFEST
-rw-r--r-- 1 42 19. Jul 15:39 MANIFEST.in
-rw-r--r-- 1 167 19. Jul 15:29 setup.py
-rw-r--r-- 15 19. Jul 15:16 test.dat
lrwxrwxrwx 18 19. Jul 15:16 test.symlink.dat -> test.dat
$ cat setup.py
from distutils.core import setup
setup(name = 'foo',
version = '0.1.0',
py_modules = ['foo'],
data_files = [("", ["test.dat", "test.symlink.dat"])])
$ python setup.py sdist --formats=gztar,zip
dist/foo-0.1.0.tar.gz does preserve the symbolic link test.symlink.dat ->
test.dat, while dist/foo-0.1.0.zip does not.
This can lead to unexpected behaviour when a symlink points to a file outside
the source tree. In the .zip file everything will be fine, while the .tar.*
file will contain a broken link.
Actual behaviour: storing of symbolic links depends on the target format.
Expected behaviour: storing of symbolic links should not depend on the target
format, i.e. format switches should be transparent. Since the zipfile module
apparently does not support symbolic links, symlinks should be dereferenced for
formats=gztar,bztar using the dereference=True parameter of tarfile.TarFile()
in archive_util.py.
--
assignee: tarek
components: Distutils
messages: 140669
nosy: eric.araujo, fberger, tarek
priority: normal
severity: normal
status: open
title: distutils dereferences symlinks for zip but not for bztar/gztar target
type: behavior
versions: Python 2.6, Python 3.2
___
Python tracker
<http://bugs.python.org/issue12585>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7639] bdist_msi fails on files with long names
Florian Berger added the comment: I can confirm that this issue persists in Python 3.1.2 on win32. The patch by cgohlke from 2010-10-22 fixes the problem here as well. -- nosy: +fberger versions: +Python 3.1 ___ Python tracker <http://bugs.python.org/issue7639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
