The project I am working on now needs to include license files for all of the 3rd party code that it includes. Since license files are not included in distribution packages, the process for doing this is exceedingly complex, error prone, and in some cases, impossible. The build process builds URLs to license files in package source code repositories based on version number, but this is dependent upon several things…
1. The source code repository is accessible via the Internet and still exists.
2. There is a tag for each version (not always true).
3. Tags follow a consistent naming pattern with respect to version numbers (not always true).
I believe that it makes sense to provide a standard means for distribution packages to include license files and then encourage package authors to use it.
Hi,
I'm modifying a python project which uses setuptools for installation.
The project installs an entry point as such:
setup_args["entry_points"] = { "console_scripts": ["w1thermsensor
= w1thermsensor.cli:cli [CLI]"] }
where [CLI] is a reference to an extra_requires entry. This entry
looks like this:
extras_require=dict(CLI="click>=7.0")
With these two lines, the current behavior is that the w1thermsensor
entry point is *always* installed when "setup.py install" is invoked,
but the entry point will cause an error if its dependencies are not
available.
I would like to change the behavior, so that the entry point is *not
installed* if the extra dependencies are not available (and perhaps
also show a warning, indicating that this entry point has not been
installed).
How can I do this?
Cheers,
Jonatan
It seems that the base images used for manylinux wheels are not publicly
available.
For example, https://quay.io/pypa/manylinux2010_centos-6-no-vsyscall gives
a 403 error ("you are not authorized to view this resource").
I think that it would make sense for reproducibility purposes to make these
images public. (I have opened an issue about this on the GitHub repository:
https://github.com/pypa/manylinux/issues/481).
Best,
/Cross-posting this announcement to both distutils-SIG and discourse.
The main discussion thread should be on the discourse
<https://discuss.python.org/t/pycon-us-2020-packaging-summit-registration-an…>./
Greetings one and all,
Though each of us cuts our own path through the harrowing jungle that is
the days of our lives, we are all inevitably drawn closer and closer to
a single fate; yes, of course I am talking about PyCon 2020’s Packaging
Summit! April is looming on the horizon, threatening to take us
unawares, but we are a crafty sort, and have prepared to meet its ambush
with a secret weapon: DILIGENT PREPARATION AND SPREADSHEETS!
In my last announcement, I asked that you save the date: *Thursday,
April 16, 2020*, but provided you no other action items. I am now coming
to you with TWO actions that you can take. /If you don’t know what the
packaging summit is, please see the website for more details
<https://us.pycon.org/2020/hatchery/packaging>./
1. *Register*! This year we will be collecting registration ahead of
time, and like the Language Summit we will be curating the list of
attendees to try and maximize the effectiveness of the limited time
we have for these discussions. In addition to people actually
working on packaging tools, we’re also looking to see people with
many different perspectives participating in the discussions, so if
you are on the fence as to whether or not you qualify but you’re
interested in participating, please register.
You can register at http://bit.ly/python-packaging-summit-2020-reg
Registration is open /now/ and we will close the registration form on
*March 7th, 2020*. All registration decisions should be finished by
*March 15th, 2020*.
2. *Propose topic for discussion*! In previous years, topics were
proposed in the room or ahead of time on discourse. This year, we’ll
be collecting discussion topics with something closer to a private
Call for Proposals, and then releasing all the discussion topics for
public voting at the same time. We’ll be doing it this way to
prevent biasing certain selections based on their position in the
voting list or length of time available to be voted on.
Topic suggestions will be evaluated independent of the submitter; please
propose any topic you would like to see discussed — you don’t have to be
the driver of an idea to propose it. We will schedule about 5 minutes at
the beginning of each discussion period for someone to give a quick
introduction to the topic. By default the person (or people) who
proposed the topic will be responsible for either giving that
introduction or delegating the task to someone else, but if one of your
proposals was selected and you cannot present or find someone to
present, the organizers will find someone to give the introduction.
You may find the topic proposal form at
http://bit.ly/python-packaging-summit-2020-topics
Topic proposal is open /now/ and will close on *March 7th, 2020*. Topic
voting is expected to run from March 9th - March 30th.
This and other information is available at our website:
https://us.pycon.org/2020/hatchery/packaging/
If you have any questions or concerns, feel free to respond on the
discourse
<https://discuss.python.org/t/pycon-us-2020-packaging-summit-registration-an…>
or to contact me or one of the other organizers.
Last week I heard for the first time about the research project FASTEN
https://www.fasten-project.eu/. "FASTEN stands for Fine-Grained Analysis
of Software Ecosystems as Networks."
> instead of analyzing dependencies at the package level, we will analyze them at the call graph level! This will allow us to be super precise when we are tracking dependencies, when we do change impact analysis, when we recommend clients to update packages etc. It will also open the door to new sophisticated applications, e.g. licensing compliance, dependency risk profiling and data-driven API evolution.
That's from the blog post by Georgios Gousios, the PI, at
http://www.gousios.gr/blog/Introducing-Fasten.html . More info:
https://www.fasten-project.eu/view/Main/Introductionhttps://www.fasten-project.eu/view/Main/Overviewhttps://www.fasten-project.eu/view/Main/Contacts
And people who are interested in dynamically and statically analyzing
call graphs in Python may be interested in "Graph Schema and its
representation" in https://www.fasten-project.eu/view/Main/Deliverables .
I've sent a note to FASTEN inviting the team to come talk about their
project here on distutils-sig, because FASTEN's site says they aim to
eventually integrate into PyPI -- I'm not 100% sure whether that means
"create a service that people can use WITH PyPI" or "get FASTEN's work
incorporated into pypi.org".
--
Sumana Harihareswara
pip project manager on contract with Python Software Foundation
Changeset Consulting
https://changeset.nyc
Hello everyone,
I am a research programmer at the NYU School of Engineering. My colleagues
(Trishank Kuppusamy and Justin Cappos) and I are requesting community
feedback on our proposal, "Surviving a Compromise of PyPI." The two-stage
proposal can be reviewed online at:
PEP 458
http://legacy.python.org/dev/peps/pep-0458/
PEP 480
http://legacy.python.org/dev/peps/pep-0480/
Summary of the Proposal:
"Surviving a Compromise of PyPI" proposes how the Python Package Index
(PyPI) can be amended to better protect end users from altered or malicious
packages, and to minimize the extent of PyPI compromises against affected
users. The proposed integration allows package managers such as pip to be
more secure against various types of security attacks on PyPI and defend
end users from attackers responding to package requests. Specifically,
these PEPs describe how PyPI processes should be adapted to generate and
incorporate repository metadata, which are signed text files that describe
the packages and metadata available on PyPI. Package managers request
(along with the packages) the metadata on PyPI to verify the authenticity
of packages before they are installed. The changes to PyPI and tools will
be minimal by leveraging a library, The Update Framework
<https://github.com/theupdateframework/tuf>, that generates and
transparently validates the relevant metadata.
The first stage of the proposal (PEP 458
<http://legacy.python.org/dev/peps/pep-0458/>) uses a basic security model
that supports verification of PyPI packages signed with cryptographic keys
stored on PyPI, requires no action from developers and end users, and
protects against malicious CDNs and public mirrors. To support continuous
delivery of uploaded packages, PyPI administrators sign for uploaded
packages with an online key stored on PyPI infrastructure. This level of
security prevents packages from being accidentally or deliberately tampered
with by a mirror or a CDN because the mirror or CDN will not have any of
the keys required to sign for projects.
The second stage of the proposal (PEP 480
<http://legacy.python.org/dev/peps/pep-0480/>) is an extension to the basic
security model (discussed in PEP 458) that supports end-to-end verification
of signed packages. End-to-end signing allows both PyPI and developers to
sign for the packages that are downloaded by end users. If the PyPI
infrastructure were to be compromised, attackers would be unable to serve
malicious versions of these packages without access to the project's
developer key. As in PEP 458, no additional action is required by end
users. However, PyPI administrators will need to periodically (perhaps
every few months) sign metadata with an offline key. PEP 480 also proposes
an easy-to-use key management solution for developers, how to interface
with a potential build farm on PyPI infrastructure, and discusses the
security benefits of end-to-end signing. The second stage of the proposal
simultaneously supports real-time project registration and developer
signatures, and when configured to maximize security on PyPI, less than 1%
of end users will be at risk even if an attacker controls PyPI and goes
undetected for a month.
We thank Nick Coghlan and Donald Stufft for their valuable contributions,
and Giovanni Bajo and Anatoly Techtonik for their feedback.
Thanks,
PEP 458 & 480 authors.
Hi;
I am new to PyPI and deleted my project (pyhma) by mistake. Is there a way to allow me to create it again with the same name? We can not change the name as it is part of a code paper under the same name.
Thanks;
Sabry
