Packaging and distribution folks: would any of you like to mentor for GSoC?
As a reminder, we have at least one current maintainer, Pradyun Gedam, who did an apprenticeship via GSoC -- probably there are more that I don't know about. If you can, consider investing in the future maintainability of your codebase by mentoring this year. :-)
(Might be worth checking whether any of your current contributors are eligible to apply for GSoC -- for instance, graduate students are eligible. https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility… )
-------- Forwarded Message --------
Subject: [PSF-Community] Google Summer of Code 2019 needs you!
Date: Tue, 29 Jan 2019 18:50:12 -0800
From: Terri Oda <terri(a)toybox.ca>
Reply-To: gsoc-admins(a)python.org <gsoc-admins(a)python.org>
To: PSF Community <psf-community(a)python.org>
Hi Python community folk!
As we've done for the past many years, Python is hoping to participate
in Google Summer of Code. This is a neat program where students write
code over the (northern hemisphere) summer under the tutelage of open
source mentors and get paid: we provide the project ideas, mentors and
choose the students, Google provides the program framework and the money
to pay students. You can read more about GSoC here:
Python participates as an "umbrella org" where many different smaller
projects ("sub orgs") that use Python can take part under our banner.
You can also participate separately, but for people who've never done it
before and want help or for whom the paperwork is a hassle, you're
welcome to join up with us and let us show you the ropes!
It's really fun, and we've gotten lots of new contributors to
Python-based projects over the years, taking in as many as 70+ students
in a single year. Last year we only had 15, though, so we've got lots
of space for new mentors and new projects.
We need a good set of sub-orgs and ideas by Feb 4th for our application,
and if we're accepted by Google we'll be able to add a few more ideas
and groups until March 5th or so.
Sound intriguing? You can read all about what we're doing at
http://python-gsoc.org/ (which has answers to questions like "what does
it take to be a mentor?" and "what does it take to be a sub-org?")
You can also send questions to gsoc-admins(a)python.org (or just hit reply
to this email!)
PSF-Community mailing list
Bundled up in the confusion about the PEP 517 rollout is the issue that
PEP 517 does not allow for PEP 517 backends to use PEP 517 to build
themselves, and how the bootstrapping should take place is left unspecified.
This is a problem for setuptools at the moment, and presumably other
build backends like flit. Since I know not everyone on this list follows
the discourse, I thought it prudent to advertise here that I've created
a thread on the Python discourse to discuss this topic:
> -----Original Message-----
> From: Antonio Cavallo <antonio.cavallo.71(a)gmail.com>
> Sent: Sunday, January 27, 2019 5:05 PM
> To: Alex Walters <tritium-list(a)sdamon.com>
> Subject: Re: [Distutils] unifying package formats
> I don't think they serve a much different scope after al:l both uncompress
> files under a filesystem. There are difference in the way .so/.dll are
> maintained/built and some ancillary metadata (and you can see commonality
> in between conda/pip as well) but that's about it.
Then, that puts 7-zip and the PYPA in the same scope. There is more to project and infrastructure scope than the technical scope of what the code is doing.
No, pip's scope is strictly managing python packages, conda's scope is much wider than that.
> On Sat, 26 Jan 2019 at 18:21, Alex Walters <tritium-list(a)sdamon.com
> <mailto:firstname.lastname@example.org> > wrote:
> > -----Original Message-----
> > From: Antonio Cavallo <antonio.cavallo.71(a)gmail.com
> <mailto:email@example.com> >
> > Sent: Saturday, January 26, 2019 6:01 PM
> > To: distutils-sig(a)python.org <mailto:firstname.lastname@example.org>
> > Subject: [Distutils] unifying package formats
> > Hi,
> > is there any initiative to share a common package format between
> conda and
> > pip? They look very similar.
> > Thanks
> They look similar, but they have very different scopes. Pip is for the
> python environment only. Conda acts more like a python focused, system-
> isolated APT. Unifying packaging for the general python ecosystem (wheels
> hosted on pypi installed with pip) with conda (full stack dependency
> management, including large quantities of foreign code) is likely to be
> impossible, and even if possible, impractical.
On behalf of the PyPA, I am pleased to announce that pip 19.0 has just
been released. This release brings support for multiple new packaging
The highlights of this release are:
- Python 3.4 support is deprecated.
- PEP 517 support is now implemented.
- manylinux2010 wheels are now supported.
- Dependency links support has been removed.
- Many bug fixes and lots of minor improvements.
In addition, when run on Python 2.7, pip 19.0 prints a warning regarding
the upcoming 2020 EOL of Python 2.7. A future version of pip will drop
support for Python 2.7.
To install pip 19.0, you can use get-pip (as described in ) or run::
python -m pip install --upgrade pip
Note that if you are using a version of pip supplied by your
distribution vendor, vendor-supplied upgrades will be available in due
The pip development team is extremely grateful to everyone in the
community for their contributions. Thanks to everyone who put so much
effort into the new release. Many of the contributions came from
community members, whether in the form of code, participation in design
discussions and/or bug reports.
I can't use pyproject.toml for some projects with "optional build dependencies" because of build isolation.
However, it would be very useful because we have also real build dependencies.
I created an issue in pip repository (https://github.com/pypa/pip/issues/6144) but it seems to be a more general problem.
I didn't find anything about such potential problem in PEP 517/518. Any thoughts how it can be solved?
In the issue, I propose this:
# Minimum requirements for the build system to execute.
requires = [
"setuptools", "wheel", "numpy", "cython", "jinja2", "fluidpythran>=0.1.7"
# packages that are used during the build only if they are installed:
optional = ["mpi4py", "pythran"]
PEP 440 contains a section that claims:
> Summary of differences from pkg_resources.parse_version [https://www.python.org/dev/peps/pep-0440/#id63]
> * Local versions sort differently, this PEP requires that they sort as greater than the same version without a local version, whereas pkg_resources.parse_version considers it a pre-release marker.
I haven't been able to find any mention of this in the setuptools changelogs, but this no longer seems to be the case:
>>> from pkg_resources import parse_version
>>> parse_version('1.0.0+dev') > parse_version('1.0.0')
Thus, it might be good to change the comment in the PEP accordingly (ideally, someone is able to figure out in which version of setuptools parse_version started to be compatible with PEP440).
I am currently developing an application called "Outbreak" and would
like to release a package to Pypi. However, there already exists a
package with that name <https://pypi.org/project/outbreak/>. It has no
description, has no functionality, and hasn't been updated in four months.
According to PEP 541, such a project is considered name squatting and is
thus to be considered invalid. May I please request that the project be
removed from the Package Index? If you would like, I can contact the
i'm software engineer at g.tec. We're building brain computer interfaces.
For one of our devices we've built a python .pyd library, that we want to
distribute and sell with our software. The user would buy a license key in
our webshop, and afterwards he'd be able to unlock and use the api in
python. With our installer we'd like to copy the library to a folder on the
users machine. By adding this path to the pythonpath, the user should be
able to use the library. We don't want to distribute python itself, just the
ibrary that we've compiled using python 3.3.
I'm having some questions according the python licensing, because it's not
completely clear for me:
* Are we allowed to provide the compiled .pyd library without the
source code for that library?
* Do we need to distribute the psf license agreement or any reference
to python within our license agreement if we distribute the library?
Martin Walchshofer, MSc | Software Engineer
g.tec medical engineering GmbH
Sierningstrasse 14 | 4521 Schiedlberg | Austria
office: <tel:0043725122240> +43 7251 22240
email: <mailto:email@example.com%20> walchshofer(a)gtec.at
w: <http://www.gtec.at> www.gtec.at
b: <http://blog.gtec.at/> blog.gtec.at
f: <https://www.facebook.com/gtecmedical> g.tec medical engineering
t: <https://twitter.com/gtec_BCI> @gtec_BCI
y: <https://www.youtube.com/channel/UCVR80bpCIQyWgyGa20OLmvw> gtec medical
l: <https://www.linkedin.com/company/1627233/> g.tec medical engineering