Distutils-SIG April 2020

distutils-sig@python.org

4 participants
5 discussions

by Pradyun Gedam

On behalf of the PyPA, I am pleased to announce a beta release of pip, pip 20.1b1 has been released. The highlights for this release are: * Significant speedups when building local directories, by changing behavior to perform in-place builds, instead of copying to temporary directories. * Significant speedups in `pip list --outdated`, by parallelizing network access. This is the first instance of parallel code within pip's codebase. * A new `pip cache` command, which makes it possible to introspect and manage pip's cache directory. * Better `pip freeze` for packages installed from direct URLs, enabled by the implementation of PEP 610. We would be grateful for all the testing that users could do, to ensure that when pip 20.1 is released, it's as solid as we can make it. This release also contains an alpha version of pip's next generation resolver. It is *off by default* because it *unstable and notready for everyday use*. As with all pip releases, a significant amount of the work was contributed by pip's user community. Huge thanks to all who have contributed, whether through code, documentation, issue reports and/or discussion. Your help keeps pip improving, and is hugely appreciated. Specific thanks go to Mozilla (through its Mozilla Open Source Support <https://www.mozilla.org/en-US/moss/> Awards) <https://www.mozilla.org/en-US/moss/> and to the Chan Zuckerberg Initiative <https://chanzuckerberg.com/eoss/> DAF, an advised fund of Silicon Valley Community Foundation, for their support that enabled the work on the new resolver.

1 month

PyPi not allowing duplicate filenames

by Chris Barker

Hi all, PyPi does not allow duplicate file names -- this makes lots of sense, because you really don't want people to go to PyPi one day and grab a file, and then go there another day, grab a file with exactly the same name, and have it be a different file. However.... We are all too human, and make mistakes when doing a release. All to often someone pushed a broken file up to PyPi, often realizes it pretty quickly -- before anyone has a chance to even download it (or only the dev team as, for testing...). In fact, I was in a sprint last summer, and we decided to push our package up to PyPi -- granted, we were all careless amateurish noobs, but we ended up making I think 4! minor version bumps because we had done something stupid in the sdist. Also -- the latest numpy release got caught in this, too: """ * We ran into a problem with pipy not allowing reuse of filenames and a resulting proliferation of *.*.*.postN releases. Not only were the names getting out of hand, some packages were unable to work with the postN suffix. """ So -- I propose that PyPi allow projects to replace existing files if they REALLY REALLY want to. You should have to jump through all sorts of hoops, and make it really clear that it is a BAD IDEA in the general case, but it'd be good to have it be possible. After all -- PyPi does not take on responsibility for anything else about what's in those packages, and Python itself is all about "we're all consenting adults here" I suppose we could even put in some heuristics about how long the file as been there, how many times it's been downloaded, etc. Just a thought.....I really hate systems that don't let me roll back mistakes, even when I discover them almost immediately... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

1 month, 2 weeks

ImportError running 'test' on namespace package - other package in namespace not found

by Jason R. Coombs

I've got two projects: mynamespace.myprojectA and mynamespace.myprojectB myprojectB depends on myprojectA. I'm using setuptools 0.6c8 to manage both projects. Both projects are registered using 'setup develop'. Both projects are accessible from an interactive interpreter: PS C:\Users\me\projects> python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import mynamespace.myprojectA >>> import mynamespace.myprojectB >>> from mynamespace.myprojectA import mymoduleZ However, when I run 'setup test' in myprojectB, the tests fail with File ".mymoduleZ.py", line NNN, in [some context] from mynamespace.myprojectA.mymoduleZ import MyClassC ImportError: No module named myprojectA.mymoduleZ In setup.py, the test_suite is nose.collector. I searched and couldn't find anyone else with this problem. Is this a supported configuration? Is there something I can do to make tests work with interdependent projects with the same root namespace? If there's not something obvious I should be doing differently, I'm happy to put together a minimal test case that reproduces the problem. Any suggestions are appreciated. Sincerely, Jason R. Coombs

1 month, 2 weeks

Failure: Error

by oliviajohn123123＠hotmail.com

facing same NOt found issue the issue code is "C:\Users\jaraco\projects\distutils_namespace\myns.projB\test\testBasic.py", can you guide me for this ? https://thelifefoundry.com/hotmail/

1 month, 2 weeks

Online talk in 90 min: how pip works internally

by Sumana Harihareswara

Pradyun Gedam is giving a talk to a local meetup group in 90 minutes on how pip works. You can watch via GoToMeeting. https://www.meetup.com/HydPyGroup/events/269498071/ > pip is the package manager for the Python ecosystem, but what actually happens when you "pip install foo"? This talk explores what pip does to install your packages. When: April 7th, 9:00 p.m - 10:00 p.m. India time It'll likely be recorded and be available on YouTube afterward. -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

1 month, 4 weeks

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG April 2020