Mailman 3 - Distutils-SIG

Question on Python Package scanning
by Prateek Mohta 09 Feb '19

09 Feb '19

Hey , I wanted to check if the packages available on Pypi.org are scanned for any security vulnerabilities or not, can you please confirm. My concern is how do you control if someone uploads a malicious code on Github Prateek Mohta Data Scientist, Data and Analytics Equifax Inc. O 770-740-5756 C 404-797-3893 [cid:image002.png@01D4BF16.AE5EC860]<http://www.equifax.com/> This message contains proprietary information from Equifax which may be confidential. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail postmaster(a)equifax.com. Equifax® is a registered trademark of Equifax Inc. All rights reserved.

5 5

PEP 517 - source dir and sys.path
by Chris Jerdonek 08 Feb '19

08 Feb '19

For those of you who participated in the PEP 517 discussion during the summer of 2017 (just prior to its provisional acceptance), I want to flag that one of the issues discussed back then has now resurfaced for discussion. This is because the feature was turned on by default in pip's latest release (19.0) less than a week ago. The issue is the one around whether the source directory should be included in sys.path. The resurfacing is more or less as predicted. For example, in one email [1] from August 29, 2017, Nick summarized the state of things by saying (not too long before provisional acceptance)-- So I think we can deem this one resolved in favour of "Frontends must > ensure the current directory is *NOT* on sys.path before importing the > designated backend", as starting there will mean we maximise our chances of > learning something new as part of the initial rollout of the provisionally > accepted API. And also-- 2. If omitting it is genuinely a problem, we'll likely find out soon enough > as part of implementing a setup.py backend Basically, that "soon enough" moment has arrived, and at least one discussion on how to resolve it has started on the tracker here: https://github.com/pypa/pip/issues/6163 There is another discussion here, but it's probably better for the discussion to be in one spot: https://github.com/pypa/setuptools/issues/1642 Maybe Discourse? --Chris [1]: https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html

9 13

Fwd: [PSF-Community] Google Summer of Code 2019 needs you!
by Sumana Harihareswara 01 Feb '19

01 Feb '19

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 31 Jan '19

31 Jan '19

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 30 Jan '19

30 Jan '19

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 28 Jan '19

28 Jan '19

> -----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 27 Jan '19

27 Jan '19

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 23 Jan '19

23 Jan '19

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 20 Jan '19

20 Jan '19

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 20 Jan '19

20 Jan '19

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