Mailman 3 January 2019 - Distutils-SIG

Fwd: [PSF-Community] Google Summer of Code 2019 needs you!
by Sumana Harihareswara Jan. 31, 2019

Jan. 31, 2019

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… ) -- Sumana Harihareswara Changeset Consulting https://changeset.nyc -------- 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: https://summerofcode.withgoogle.com/ 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!) Terri _______________________________________________ PSF-Community mailing list PSF-Community(a)python.org https://mail.python.org/mailman/listinfo/psf-community

1 0

Update PEP 508 to allow version specifiers
by Jan Musílek Jan. 31, 2019

Jan. 31, 2019

Hello! I hope I'm addressing this issue to the right place. Pradyun Gedam suggested [1] to open the discussion here. PEP 508 dependency specification [2] is generally considered to be replacement for dependency links. However, version specifiers are missing from PEP 508, so I can't specify: package >= 10.0 @ https://github.com/owner/package.git I can specify the exact version with tag: package @ https://github.com/owner/package.git@10.0 However, this is rather a hack than a real replacement. So, I'm proposing to update PEP 508 to allow version specifiers. The url_req rule [3] could be updated as follows: url_req = name wsp* extras? wsp* versionspec? wsp* urlspec wsp+ quoted_marker? However, there is an issue with overspecifying. What if I do this? package > 10.0 @ https://github.com/owner/package.git@10.0 Should this be considered an error? No such version available? I think so, but maybe it should be specified in the PEP as well? What do you think? I've never proposed any PEP update before, so there may be some procedures I'm missing. If so, please point me in the right direction. Kind regards, Jan Musílek [1] https://github.com/pypa/pip/issues/6162#issuecomment-458280052 [2] https://www.python.org/dev/peps/pep-0508/ [3] https://www.python.org/dev/peps/pep-0508/#grammar

12 37

PEP 517 Backend boostrapping
by Paul Ganssle Jan. 30, 2019

Jan. 30, 2019

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: https://discuss.python.org/t/pep-517-backend-bootstrapping/789

1 0

Re: unifying package formats
by Alex Walters Jan. 28, 2019

Jan. 28, 2019

> -----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:tritium-list@sdamon.com> > wrote: > > > > -----Original Message----- > > From: Antonio Cavallo <antonio.cavallo.71(a)gmail.com > <mailto:antonio.cavallo.71@gmail.com> > > > Sent: Saturday, January 26, 2019 6:01 PM > > To: distutils-sig(a)python.org <mailto:distutils-sig@python.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. > >

1 0

unifying package formats
by Antonio Cavallo Jan. 27, 2019

Jan. 27, 2019

Hi, is there any initiative to share a common package format between conda and pip? They look very similar. Thanks

3 2

pip 19.0 is now available!
by Pradyun Gedam Jan. 22, 2019

Jan. 22, 2019

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 standards. 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 [1]) 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 course. 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. [1]: https://pip.pypa.io/en/latest/installing Best, Pradyun

1 0

pyproject.toml (PEP518), build isolation (PEP517) and optional build dependencies
by PIERRE AUGIER Jan. 20, 2019

Jan. 20, 2019

Hi, 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: ``` [build-system] # 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"] ``` Pierre Augier

3 2

PEP 440
by Michael Goerz Jan. 20, 2019

Jan. 20, 2019

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') True 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). Best, Michael Goerz

2 1

PEP 541
by Elliot Paton-Simpson Jan. 17, 2019

Jan. 17, 2019

Hello, 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 author myself. Thank you, Elliot Paton-Simpson

2 1

license python api
by Martin Walchshofer Jan. 17, 2019

Jan. 17, 2019

Hello, 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? Best, Martin Martin Walchshofer, MSc | Software Engineer g.tec medical engineering GmbH Sierningstrasse 14 | 4521 Schiedlberg | Austria office: <tel:0043725122240> +43 7251 22240 email: <mailto:walchshofer@gtec.at%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 engineering l: <https://www.linkedin.com/company/1627233/> g.tec medical engineering GmbH

1 0