Hello,
I would like to draw attention to https://bugs.python.org/issue32773
Currently, distutils (and everything that uses it, such as setuptools
and pip) installs files with the same timestamp as in the sources (I'm
only discussing copied files, not generated/compiled files). In other
On 2018-08-04 14:02, Thomas Kluyver wrote:
On Sat, Aug 4, 2018, at 9:34 AM, Paul Moore wrote:
Whether timestamps are
preserved by the wheel building process depends on the build system -
so the question boils down to "does setup.py bdist_wheel preserve
timestamps?" in the case of the setuptools
The fact that installs from wheels don't preserve timestamps is a very
good argument that it's OK to NOT preserve timestamps in general. Any
package which would rely on preserving timestamps would already be
broken when installing using a wheel.
By the way, initially I thought that this was a
On 2018-08-04 00:02, Chris Jerdonek wrote:
I'm not sure how relevant it is, but this issue was recently filed on
pip's issue tracker ("Reproducible installs"):
https://github.com/pypa/pip/issues/5648
This seems to be about preserving timestamps when extracting wheel files.
There is also an
On 2018-08-04 10:34, Paul Moore wrote:
Jeroen seemed to say he agreed with this, but
I'm not sure I see how that matches his stated requirement for
installs to not preserve timestamps...
The way how pip currently works (I assume that this stays the case) is
that it uses a temporary build
Proposal: change timestamps of files installed from a wheel to the time
of installation, except for .py files.
**Existing situation**
Let's consider two ways of installing a Python package: installation
from a source tarball and installation from a wheel, in both cases using
"pip install".
On 2018-08-06 19:49, Chris Jerdonek wrote:
Does this proposal mean that .pyc files would need to be regenerated
after installing from a wheel (because the timestamp inside the .pyc
file would no longer match the .py file from which it came)?
No, I specifically mentioned that the timestamps of
Hello,
I have a Python project that depends on an external C library (which is
unrelated to Python and NOT part of the OS).
For an sdist, this is easy: my setup.py assumes that the library is
pre-installed somewhere on the system where setuptools can find it.
However, is there a standard
On 2018-09-14 16:39, Paul Moore wrote:
My understanding (and I'm not an expert here, so hopefully someone
else will confirm or correct) is that yes, the data directory is
installed to "the installation root", which is $VIRTUAL_ENV for a
virtualenv, and "something else" for non-virtualenvs (I
On 2018-09-14 12:55, Alex Grönholm wrote:
I'm curious: what data does it attempt to install and where? Have you
created a ticket for this somewhere?
The OP mentioned absolute paths. However, it really sounds like a bad
idea to hard-code an absolute installation path. Let's consider it a
On 2019-01-22 13:04, Robert T. McGibbon wrote:
It's necessary to bundle the external library with the wheel.
On linux, this is what the manylinux tag is all about (see PEP 513 &
571) and the auditwheel tool (https://github.com/pypa/auditwheel) will
bundle the library into the wheel.
On OS X
11 matches
Mail list logo
