On 4 August 2018 at 03:34, Chathika Gunaratne
> Dear Admin,
> I am writing to you regarding the Package Index name emd. I am a PhD student
> at the University of Central Florida and for my dissertation, I have
> recently developed a Python software, Evolutionary Model Discovery, which I
> am assembling into a package, EMD. https://github.com/chathika/EMD
> However, I noticed that there is already a package named emd on pypi.org.
> This package seems abandoned with just one release in February 2012 and no
> contact information about the author,
> https://pypi.org/project/emd/1.0/#history .
> I read about PEP 541 https://www.python.org/dev/peps/pep-0541/ and was
> curious as to if it is still possible that I can acquire the package name
> EMD. I wanted to make sure of this before I went ahead with the name EMD for
> my package, please.
Generally speaking its not whether a package has been updated that
matters, its whether the package is in use: if its published in
debian/suse/fedora, if its getting downloads, then taking over the
name is going to have negative consequences.
That said, this has had 0 downloads per the bigtable statistics (0 for
all recorded time) so in this case that seems unlikely.
I see that there is almost no mention of private packages index in the
packaging guide, and no recommendation on what to use.
Currently googling for private packages mostly return obsolete (and not
very practical) recommendations based on dependency links.
In 2018, what would be the recommended practices for teams that develop
private packages that depend on each 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 backend - which is really a
>> question for the wheel project. In the more general case, you'd have
>> to ask the same question of flit, and any other backends you cared
> IIRC, Flit will preserve the timestamps of the files when you build a wheel
For the record: my post wasn't about *building* a wheel, but about
*installing* a wheel.
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"):
This seems to be about preserving timestamps when extracting wheel files.
> There is also an older (closed) pip issue that might be relevant
> ("Preserving timestamps on copy"):
This is a different issue about preserving timestamps from the source
directory to the temporary build directory.
So both are different issues, and I agree with both: during the source
extraction and build process, you want to preserve timestamps as much as
possible. But for the installation, you do NOT want to preserve timestamps.
On 2018-08-04 13:16, Paul Moore wrote:
> Can you give a
> specific example of an end to end process where the packaging
> toolchain's current behaviour gives demonstrably the wrong result?
Yes I can. I will work out a detailed proposal about timestamps in the
build/install process in general. But please give me some time to write
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 distutils issue, but
it's clear now that it's really a pip issue.
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 directory for everything, for example
So concretely for a wheel install:
(A) Extract the wheel in build directory
(B) Generate .pyc files in build directory
(C) Copy files from build directory to final installation directory in
The way I understand it, https://github.com/pypa/pip/issues/5648 is
about (A) while my proposal is about (C). So I think that timestamps
should be preserved in (A) but not for (C).
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
words, it preserves the timestamp when it copies the file from source to
installation directory. There is a comment in the distutils sources
# XXX copy_file by default preserves atime and mtime. IMHO this is
# the right thing to do, but perhaps it should be an option -- in
# particular, a site administrator might want installed files to
# reflect the time of installation rather than the last
# modification time before the installed release.
It just says "IMHO, this is the right thing to do" without any
Now IMHO, preserving timestamps is NOT the right thing to do: the
timestamp of installed files should be the time of installation.
Autotools (which is probably the most-used installer for open
source/free software projects) does that.
The reason why preserving timestamps is bad is because it breaks
dependency checking: when you install something, you typically want to
rebuild other things depending on it. For .py files, this isn't relevant
(nothing depends on them), but it is relevant for .h files and certain
So I suggested in bpo-32773 to fix this. The main open question is: to
what extent could this break backwards compatibility? Personally, I
cannot imagine a case where it is important that timestamps are preserved.
If it's decided that this should become optional, it should be done on a
per-project basis (and not by the user installing the package). For
example, I would want all my projects to not preserve timestamps.
Suggestions on how to do this (a new argument to setup()?) are welcome.
PS: if you're interested in the history, this goes back to
Author: Greg Ward <gward(a)python.net>
Date: Mon Mar 22 14:55:25 1999 +0000
First checkin of real Distutils command modules.
So yes, I want to change a 19-year old "feature".
I am writing to you regarding the Package Index name emd. I am a PhD student at the University of Central Florida and for my dissertation, I have recently developed a Python software, Evolutionary Model Discovery, which I am assembling into a package, EMD. https://github.com/chathika/EMD
However, I noticed that there is already a package named emd on pypi.org. This package seems abandoned with just one release in February 2012 and no contact information about the author, https://pypi.org/project/emd/1.0/#history .
I read about PEP 541 https://www.python.org/dev/peps/pep-0541/ and was curious as to if it is still possible that I can acquire the package name EMD. I wanted to make sure of this before I went ahead with the name EMD for my package, please.
Looking forward to your reply.
Graduate Research Assistant,
Complex Adaptive Systems Lab
University of Central Florida,
Room 314, Engineering II,
12800 Pegasus Dr.,
Orlando, FL 32816-2993