Mailman 3 - Distutils-SIG

Shutting down distutils-sig, for real
by Andrew M. Kuchling 30 Dec '21

30 Dec '21

Shutting down the distutils-sig mailing list has been suggested since December 2020, notably by Pradyun Gedam who also raised the issue again in May 2021. However, everyone seems nervous about making the final decision. Well, I'm still the moderator of the list, so I'm happy to make that call: let's shut the list down for 2021! Steps I'll take: * Edit the list's one-line description to "Former list for Python packaging ecosystem discussion. Now archived." * Edit the list's long description to be in the past tense, and to point people at the right category on discuss.python.org. * Change the default action for the list for members and non-members to 'Reject (with notification)'. * Clear the list of members by unsubscribing everyone. * Clear the email addresses listed in the 'accept these nonmembers' field. * Submit a PR for the Python docs to remove 'distutils-sig(a)python.org' as author of a few sections. Are there other PyPA repos that might reference the list? I'll aim to do all of these tomorrow, on the last day of year. --amk

3 2

ANN: distlib 0.3.4 released on PyPI
by Vinay Sajip 08 Dec '21

08 Dec '21

I've recently released version 0.3.4 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: * Fixed #153: Raise warnings in get_distributions() if bad metadata seen, but keep going. * Fixed #154: Determine Python versions correctly for Python >= 3.10. * Updated launcher executables with changes to handle duplication logic. Code relating to support for Python 2.6 was also removed (support for Python 2.6 was dropped in an earlier release, but supporting code wasn't removed until now). A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.4/ [2] https://distlib.readthedocs.io/en/0.3.4/ [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

PEP 440
by Johnathan Irvin 16 Nov '21

16 Nov '21

Noticed the link was broken for RFC 2119. I believe it should be https://datatracker.ietf.org/doc/html/rfc2119 and currently points to http://tools.ietf.org/html/rfc2119.html Thanks, Johnathan Irvin https://twitter.com/_JohnnyIrvin https://www.linkedin.com/in/johnnyirvin/

3 2

Question from a Beginner
by Sonic Emitter3000 24 Sep '21

24 Sep '21

Hello, hope you're doing well. I greatly appreciate the effort of you people to make open source projects like you do, but I must ask. I have heard that security is quite lax when installing modules using the most popular sites for Python modules. Would you know of how I would protect myself more from potentially malicious fakes of popular Python modules?

2 2

ANN: distlib 0.3.3 released on PyPI
by Vinay Sajip 22 Sep '21

22 Sep '21

I've recently released version 0.3.3 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: * Fixed #152: Removed splituser() function which wasn't used and is deprecated. * Fixed #149: Handle version comparisons correctly in environment markers. * Add ARM-64 launchers and support code to use them. Thanks to Niyas Sait and Adrian Vladu for their contributions. * Fixed #148: Handle a single trailing comma following a version. Thanks to Blazej Floch for the report and suggested fix. * Fixed #150: Fix incorrect handling of epochs. * Reverted handling of tags for Python >= 3.10 (use 310 rather than 3_10). This is because PEP 641 was rejected. * Added a GitHub Actions workflow to perform tests. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.3/ [2] https://distlib.readthedocs.io/en/0.3.3/ [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

ANN: distlib 0.3.2 released on PyPI
by Vinay Sajip 31 May '21

31 May '21

I've recently released version 0.3.2 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: * Fixed #139: improved handling of errors related to the test PyPI server. * Fixed #140: allowed "Obsoletes" in more scenarios, to better handle faulty metadata already on PyPI. * Fixed #141: removed unused regular expression. * Fixed #143: removed normcase() to avoid some problems on Windows. * Fixed #146: added entry for SourcelessFileLoader to the finder registry. * Fixed #147: permission bits are now preserved on POSIX when installing from a wheel. * Made the generation of scripts more configurable. * Added support for manylinux wheel tags. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.2/ [2] https://distlib.readthedocs.io/en/0.3.2/ [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

Archive this list & redirect conversation elsewhere?
by Pradyun Gedam 09 May '21

09 May '21

TL;DR: OK to archive this mailing list? Reply by Aug 30th. Below: Context, Proposal, Reasoning, and timeline. *Context*: For multiple years now, we've been advising users to use setuptools and to move away from using distutils. There has been a long standing plan [^1] to vendor distutils into setuptools to allow it to evolve independently of the Python standard library and to allow for removal of distutils from the Python standard library. Recently, setuptools adopted the distutils [^2] which, as far as I can tell, starts the long process of removing distutils from the Python standard library. PEP 517 [^3] also removed the special status of distutils/setuptools as the only pipeline that can be used for generating distributions for Python projects. For some time now, "distutils" has not been a "primary" tool in the broader Python Packaging ecosystem, with setuptools being an overall superior tool that also has a good interoperability story with the other Python packaging tooling. This is acknowledged in the description of this mailing list as: > Now, it's better described as the "packaging interoperability SIG", > where issues that cut across different parts of the Python packaging > ecosystem get discussed and resolved. However, this mailing list is no longer serving this stated role either, with the Packaging category on discuss.python.org becoming the primary location for packaging tool interoperability discussions. Over the last year, the Packaging category on discuss.python.org had 841 active topics, with only 40 topics with 3 or fewer responses. [^5] In the last 100 days, the Packaging category on discuss.python.org has had 91 active topics. More than 10 PEPs have been discussed in the Packaging category on discuss.python.org in the last 100 days. Over the last year, distutils-sig had ~109 active threads, with (based on a quick skim) most having 3 or fewer responses/posters. [^4] In the last 100 days, distutils-sig has had 32 active threads (at least 7 of these have the same subject as another thread with Re:/Fwd: added). There has been only 1 PEP-related feedback discussion on distutils-sig in the last year. Most of the other threads are user support requests or announcements. *Proposal*: I suggest that, one month from now, we stop posting to this list (distutils-sig(a)python.org) and archive it. *Reasoning*: I think we do not use this mailing list for its dedicated purpose, and it does not serve any secondary function that isn't better served by a different communication channel already. (1) this mailing list is no longer the primary location for interoperability discussions (2) we have better channels for user support requests (such as issue trackers of various projects, packaging-problems etc.) (3) we have other channels for making announcements (such as the pypi-announce mailing list, the PyPA twitter account, discuss.python.org etc.) *Timeline*: Here's what I suggest, and what I will carry out if there is no objection. In one month, on August 30th, I would verify that no one has argued here for why this mailing list should not be closed/archived. Or, even if a few people have objected to closing the list, I would check for rough consensus, especially of people who are doing SOMETHING productive having to do with Python Packaging (such as maintainers of Python packages, maintainers of Python Packaging tooling, folks running key infrastructure, etc.). Then, I would request the list administrators to post a final message to this list (marking its close and suggesting that people use discuss.python.org instead) and, to archive this mailing list. This would leave archives available at their current URLs, so links, browsing and search would work. And finally, I would look through relevant documentation within PyPA repositories to see what needs updating (READMEs and so on pointing to the old list), and submit pull requests. I appreciate the work folks here have done to carry forward Python packaging over the past 21 years of this mailing list. I don't mean to diminish that or to insult anyone here. I want to help us out, and I think closing this list will help focus our energy better. But I am open to hearing that I am wrong. Realizing-that-distutils-sig-is-older-than-me-ly, Pradyun Gedam [^1]: https://www.pypa.io/en/latest/roadmap/#vendor-distutils-into-setuptools [^2]: https://github.com/pypa/setuptools/pull/2143 [^3]: https://www.python.org/dev/peps/pep-0517/ [^4]: https://mail.python.org/archives/list/distutils-sig@python.org/latest?count… [^5]: https://discuss.python.org/c/packaging/14/l/top/yearly?order=posts

11 19

Re: PEP 440 Issue
by Nick Coghlan 27 Apr '21

27 Apr '21

Hi Bianca, The ".taskslab11419" section of your version name doesn't meet the requirements for version numbers described in https://www.python.org/dev/peps/pep-0440/#public-version-identifiers, as the only non-numeric text elements permitted are "a" (alpha releases), "b" (beta releases), "c" (release candidates), "dev" (dev releases), and "post" (post-releases). The simplest resolution would be to drop the ".taskslab11419" section, and just make the version 0.2.0 instead. Alternatively, if keeping the number is important, you could make a dev release (0.2.0.dev11419), or use a 4 segment version number (0.2.0.11419). Cheers, Nick. On Tue, 27 Apr 2021 at 14:01, Bianca Reyes <biancamoniquereyes(a)gmail.com> wrote: > Hi Nick and Donald, > > > > > > I’m emailing you because I can’t seem to resolve an issue with my project > wherein I try to install using pip command and it returns: > > > > WARNING: Built wheel for SomeProject is invalid: Metadata 1.2 mandates PEP 440 version, but '0.2.0.taskslab11419' is not > > Failed to build SomeProject > > > > I’ve read your documentation with PEP 440 version but my version name > *0.2.0.taskslab11419* does not seem to be invalid based on your > documentation. Can you guys help me out here? I’ve been trying to fix this > for almost a week now but to no avail. > > > > > > Btw, I’m using python3.8 and pip 21.1 version. > > > > > > Hoping to hear from you soon. > > > > > > > > Thank you and cheers, > > Bianca > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. > www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> > <#m_3295279858084880915_m_7829119531011239564_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

PSF hiring full-time project/community manager for packaging
by Sumana Harihareswara 15 Apr '21

15 Apr '21

Great news: [the Python Software Foundation is **hiring a full-time project manager/community manager for Python's packaging toolchain**](https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-python-…. Thanks to [Bloomberg](https://www.techatbloomberg.com/blog/supporting-the-python-commu… for the funding! Please [read the announcement](https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-python…, check out [the job description](https://www.python.org/jobs/5317/), and spread the news. Please apply by May 18th, 2021. The job is remote and you can apply from anywhere in the world. As the description says: "Total compensation will range from $100k-$125k USD based on qualifications and experience." And you'd report to @EWDurbin Ee W. Durbin III, a colleague I strongly recommend and love working with. I [blogged about why this role is critical](https://www.harihareswara.net/sumana/2021/04/13/1). This new position does build on activities I've led, so I figured I'd explicitly say: I won't be applying for it. I'm going to be, instead, excited to collaborate with this person and help them learn all the stuff I know, so that in the long run, we'll have more people, with that set of skills and domain knowledge, working on Python packaging. I'll concentrate on the Python supply chain security piece specifically (via [the NSF-funded work at NYU](https://discuss.python.org/t/new-packaging-security-funding-nyu/7792)). -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

1 0

Packaging optional, arch-dependent, pre-built libraries
by Vincent Pelletier 15 Apr '21

15 Apr '21

Hello, I'm the author of python-libusb1, a pure-python ctypes wrapper for libusb1. Until recently, I had been purely relying on OS-linker-provided libusb1 (distro-installed on GNU/Linux and *BSD, fink/macports/... on OSX, ...). Then, I've been requested to bundle the libusb1 dll on windows (x86 and x86_64 wheels) because otherwise distributions seems exceedingly painful for applications using my module. With some extra code to setup.py to fetch, unzip and copy[1] the dlls, plus a now even more multi-stage distribution process (sdist, both windows wheels, in addition to the existing sign and twine steps), and it ipso facto works. Now, I'm asked to add pyinstaller compatibility, as it on its own overlooks the dll. Which makes me feel that I am maybe not using the best possible way to bundle these. From my reading of distutils and setuptools, my understanding is that a package is that non-pure-python packages contain: - stuff they built themselves (build_ext & friends) - third-party libraries that the stuff they built themselves is linked against Having nothing to build, I cannot seem to reach the library inclusion step. What is the recommended way of bundling a third-party-built arch-dependent library in an otherwise pure-python package ? [1] https://github.com/vpelletier/python-libusb1/blob/49f7f846bdd3c3d0f2ec3a01c… Regards, -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1

4 7

Making setup.py run external command to build
by Julian Smith 02 Apr '21

02 Apr '21

Hello I have a project with a fairly involved build process where we generate C++ via a python-clang-based code analyser, generates Python bindings for the resulting C++ API with SWIG, and finally compile and link to create various .so's and .py files. I'd like to package things up with a setup.py script, but from what i have read, it looks like distutils expects to compile, link and run swig itself, using distutils.core.setup()'s ext_modules arg? Is there a way to write setup.py so that it instead runs an external command (e.g. 'cd foo && make all') when it is asked to build? Thanks for any help, - Jules -- http://op59.net

7 19

New packaging security funding & NYU
by Sumana Harihareswara 21 Mar '21

21 Mar '21

Good news! New York University -- specifically Professor Justin Cappos -- and I have successfully asked the US National Science Foundation for a grant to improve Python packaging security. The NSF is awarding NYU $800,000 over two years -- from mid-2021 to mid-2023 -- to further improve the pip dependency resolver and to integrate The Update Framework further into the packaging toolchain. https://nsf.gov/awardsearch/showAward?AWD_ID=2054692&HistoricalAwards=false For what we're planning to do, what this means in the short term, an explanation of why NYU and the NSF are involved, and thank-yous, please see https://discuss.python.org/t/new-packaging-security-funding-nyu/7792 . -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

5 4

multibuild failure
by Robin Becker 25 Feb '21

25 Feb '21

Not sure exactly what broke in the chain of my toolset for building reportlab. I have a github action which fails with the message ls: cannot access /opt/python/cp27-cp27mu/bin: No such file or directory so because I have fixed the checkout version of the multibuild area itself I suppose that something else changed/updated since the last build which was successful on Jan 22. has multibuild / manylinux decided to abandon the python 2.7 version or is there something I can do to get my builds going again? As an aside is it worth trying to fix the version of multibuild or should I just assume that most of the variability will come from the many docker layers that seem to be used. > Digest: sha256:efc8a9832a07678fc17026ab35aa6444c02a665ccd5e6552c90d036045d78b17 > Status: Downloaded newer image for quay.io/pypa/manylinux2010_x86_64:latest > + break > quay.io/pypa/manylinux2010_x86_64:latest > + '[' 5 -eq 0 ']' > + return 0 > + docker run --rm -e 'BUILD_COMMANDS=build_wheel reportlab' -e PYTHON_VERSION=2.7 -e MB_PYTHON_VERSION=2.7 -e UNICODE_WIDTH=32 -e BUILD_COMMIT=HEAD -e CONFIG_PATH=.travis-config.sh -e ENV_VARS_PATH= -e WHEEL_SDIR=wheelhouse -e MANYLINUX_URL= -e BUILD_DEPENDS= -e USE_CCACHE= -e REPO_DIR=reportlab -e PLAT=x86_64 -e MB_ML_VER=2010 -v /home/runner/work/reportlab-mirror/reportlab-mirror:/io -v /home/runner:/parent-home quay.io/pypa/manylinux2010_x86_64 /io/multibuild/docker_build_wrap.sh > ls: cannot access /opt/python/cp27-cp27mu/bin: No such file or directory > Error: Process completed with exit code 2. -- Robin Becker

2 2

Re: Building Pre-releases with setup.cfg
by Matthew Gilbert 10 Feb '21

10 Feb '21

Thanks Jeremy, I will check those out. I thought that maybe there was a simple flag I could pass in to python -m build that would allow me to override a value in setup.cfg, but I should probably read through PEP517/PEP518 in full to get a better overview of this process. > > > From: Jeremy Stanley <fungi(a)yuggoth.org> > Date: Tue, Feb 9, 2021 at 3:26 PM > Subject: [Distutils] Re: Building Pre-releases with setup.cfg > To: <distutils-sig(a)python.org> > > > On 2021-02-09 09:48:31 -0500 (-0500), Matthew Gilbert wrote: > > I'm wondering if it is possibly to build pre-release tags using only a > > setup.cfg file? From > > > https://setuptools.readthedocs.io/en/latest/userguide/distribution.html#tag… > > it seems like this is possible via setup.py, but I was unable to find > > anything related to setup.cfg. > [...] > > Possibly this can be configured using the --config-setting flag but I > have > > been unable to get this to work or find any documentation on it. Ideally > I > > would be able to pass a string so I can build a dev version for testing > > uploads to Test PyPI, e.g. "0.0.1devHASH" > [...] > > I'm probably misunderstanding your question, but typically I've seen > something like PBR or Setuptools-SCM used to automatically calculate > the version at dist build time (including inferring something based > on the number of commits on the branch since the last tag, embedding > abbreviated Git commit IDs, or whatever). > -- > Jeremy Stanley > -- > Distutils-SIG mailing list -- distutils-sig(a)python.org > To unsubscribe send an email to distutils-sig-leave(a)python.org > https://mail.python.org/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/archives/list/distutils-sig@python.org/message/PUAS… >

1 0

Building Pre-releases with setup.cfg
by Matthew Gilbert 09 Feb '21

09 Feb '21

Hi all, I'm wondering if it is possibly to build pre-release tags using only a setup.cfg file? From https://setuptools.readthedocs.io/en/latest/userguide/distribution.html#tag… it seems like this is possible via setup.py, but I was unable to find anything related to setup.cfg. An abridged version of my setup.cfg file looks like [metadata] name = tester_project version = attr: tester_project.__version__ [bdist_wheel] universal=1 [build-system] requires = setuptools >= 40.9.0 wheel build-backend = setuptools.build_meta Which I was building using $ python -m build --sdist --wheel --outdir dist Possibly this can be configured using the --config-setting flag but I have been unable to get this to work or find any documentation on it. Ideally I would be able to pass a string so I can build a dev version for testing uploads to Test PyPI, e.g. "0.0.1devHASH" Any info or references is much appreciated! Thanks, Matt

2 1

Twine 3.3.0 released
by Brian Rutledge 24 Dec '20

24 Dec '20

https://pypi.org/project/twine/3.3.0/ Changelog (now via towncrier): https://twine.readthedocs.io/en/latest/changelog.html Notable improvements include more `twine upload --verbose` output, and a `--strict` option for `twine check`.

1 0

Python-Setuptools EOL Versions?
by Symphoni Bush - NOAA Affiliate 16 Dec '20

16 Dec '20

Good afternoon, I am trying to find out if there are any end-of-life versions for Python-Setuptools, and if so, when do these versions typically become EOL/unsupported? If this information is publicly stored anywhere please let me know. Thanks.

1 0

AWS Glue: Easy_Install usecase
by simon.jones＠axtria.com 15 Dec '20

15 Dec '20

Hi everyone, https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html instructed me that the mailing list would like to know any use cases where Easy_install is felt needed and I believe I have one. and I do not see any posts about this specific use case. AWS Glue is a serverless runtime environment offered by AWS, usually it runs Spark jobs but Jan 22, 2019 they released Python Shells to run quick snippet codes. they have a fairly comprehensive list of preinstalled libraries and allow you to specify wheels and eggs for anything additional stored on an S3 that you would need, with one limitation - no C-extensions, Cython wheels cannot be installed. for my use-case I needed to access some SFTPs but Paramiko depends on cryptography for SSH shenanigans and cryptography (along with its dependencies cffi, PyNaCL, and bcrypt) are CPython. Turns out if you install at runtime there is no issue - it's just with initial setup that has the limitation. of course you then have to install every time that a process runs during paid runtime, rather than startup but better that then not at all. I tried 2 approaches to install at runtime: subprocess.call(['pip' ...]) and setuptools.command.easy_install.main() subprocess.call to pip installs pure python very nicely, but every time it hit a CPython wheel/tarball - CFFI, PyNaCl, bcrypt, cryptography, and paramiko - took 6-7 minutes EACH just to install (files were provided locally, downloaded from the S3 from previous attempt seeing what would happen if you just gave it CPython ) In a separate run setuptools...easy_install processed everything in 2 seconds. Somewhere between pkg_resources.getdistribution('paramiko').activate(), importing them, and setting host keys lead to Main process starting a little less than 2 minutes later. Required use-case? Not technically Fringe use-case? Fairly Appreciated that this is still around? Very much, 2-minute startup runtime is appreciated over upwards of half an hour on every single run.

1 0

pip 20.3 release (new resolver as default)
by Sumana Harihareswara 13 Dec '20

13 Dec '20

On behalf of the PyPA and the pip team, I am pleased to announce that we have just released pip 20.3, a new version of pip. You can install it by running `python -m pip install --upgrade pip`. [Cross-posted to https://discuss.python.org/t/announcement-pip-20-3-release/5948 which will be easier to read in a web browser and to link to.] This is an important and disruptive release -- we [explained why in a blog post last year](https://pyfound.blogspot.com/2019/12/moss-czi-support-pip.html). We even made [a video about it](https://www.youtube.com/watch?v=B4GQCBBsuNU). ## Highlights * **DISRUPTION**: Switch to the new dependency resolver by default. (#9019) Watch out for changes in handling editable installs, constraints files, and more: https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-res… * **DEPRECATION**: Deprecate support for Python 3.5 (to be removed in pip 21.0) (#8181) * **DEPRECATION**: pip freeze will stop filtering the pip, setuptools, distribute and wheel packages from pip freeze output in a future version. To keep the previous behavior, users should use the new `--exclude` option. (#4256) * Substantial improvements in new resolver for performance, output and error messages, avoiding infinite loops, and support for constraints files. * Support for PEP 600: Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions. (#9077) * Documentation improvements: Resolver migration guide, quickstart guide, and new documentation theme. * Add support for MacOS Big Sur compatibility tags. (#9138) The new resolver is now *on by default*. It is significantly stricter and more consistent when it receives incompatible instructions, and reduces support for certain kinds of constraints files, so some workarounds and workflows may break. Please see [our guide on how to test and migrate, and how to report issues](https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020). You can use the deprecated (old) resolver, using the flag `--use-deprecated=legacy-resolver`, until we remove it in the pip 21.0 release in January 2021. You can find more details (including deprecations and removals) [in the changelog](https://pip.pypa.io/en/stable/news/). ## User experience Command-line output for this version of pip, and documentation to help with errors, is significantly better, because you worked with our experts to test and improve it. [Contribute to our user experience work: sign up to become a member of the UX Studies group](https://bit.ly/pip-ux-studies) (after you join, we'll notify you about future UX surveys and interviews). ## What to expect in 20.1 We aim to release pip 20.1 in January 2021, per our [usual release cadence](https://pip.pypa.io/en/latest/development/release-process/#release-cadence). You can expect: * Removal of [Python 2.7](https://pip.pypa.io/en/latest/development/release-process/#python-2-support) and 3.5 support * Further improvements in the new resolver * Removal of legacy resolver support ## Thanks 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) and to the [Chan Zuckerberg Initiative](https://chanzuckerberg.com/eoss/) DAF, an advised fund of Silicon Valley Community Foundation, for their funding that enabled substantial work on the new resolver. That funding went to [Simply Secure](https://simplysecure.org/) (specifically Georgia Bullen, Bernard Tyers, Nicole Harris, Ngọc Triệu, and Karissa McKelvey), [Changeset Consulting](https://changeset.nyc/) (Sumana Harihareswara), [Atos](https://www.atos.net) (Paul F. Moore), [Tzu-ping Chung](https://uranusjr.com), [Pradyun Gedam](https://pradyunsg.me/), and Ilan Schnell. Thanks also to Ernest W. Durbin III at the Python Software Foundation for liaising with the project. -- Sumana Harihareswara, pip project manager Changeset Consulting https://changeset.nyc

2 2

Installation Instructions for Python?
by Cort, Brian 11 Dec '20

11 Dec '20

Hello, We were trying to create an automated installation process. As part of this, our software deployment team has requested the installation instructions, which I was unable to locate. Can you help by pointing me towards them? Thank you, Brian Brian Cort | Application Analyst Kroger Technology: Point of Sale | The Kroger Co. office: 503.797.3229 cell: 971.293.6244 [cid:image001.png@01D6CD4D.01E06F70] For more POS related information, please feel free to see our publicly accessible Wiki/Confluence Site: https://confluence.kroger.com/confluence/x/BySXBQ ________________________________ This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

4 3

Critical problem in PyCharm caused by the removal of "--build-dir" in 2020.3
by Mikhail Golubev 01 Dec '20

01 Dec '20

Hi there! I'm a member of the PyCharm team, and we faced a rather critical issue with the release of pip 2020.3 (https://youtrack.jetbrains.com/issue/PY-45712). It turned out that we actually still used the "--build-dir" option in our internal scripts for installing packages through pip, and we completely missed the fact that it was deprecated. To make the matter worse, a few releases back we implemented automatic upgrading of packaging tools in all virtual environments created in the IDE, so now it's impossible to install anything in a new project unless pip is explicitly downgraded first. Judging by how pip now operates regarding building of packages, this option can be safely dropped in our wrappers, but we still need some time to prepare and test patches for a few previous releases and upcoming 2020.3. Is it possible to give us some time to soften the blow for the users? The second question is about the behavior of this option. It appears that we initially started using it because in the past packages were not built in a temporary directory by default. Could you please point me to the exact version of pip where it changed? -- I couldn't find it in a changelog. It would help us decide whether we need to keep some compatibility layer for interpreters with an old version of pip installed. Thanks a lot!

4 4

Announcement: pip 20.2 release!
by Pradyun Gedam 23 Oct '20

23 Oct '20

On behalf of the PyPA, I am pleased to announce that we have just released pip 20.2, a new version of pip. You can install it by running python -m pip install --upgrade pip. The highlights for this release are: - The beta of the next-generation dependency resolver is available - Faster installations from wheel files - Improved handling of wheels containing non-ASCII file contents - Faster pip list using parallelized network operations - Installed packages now contain metadata about whether they were directly requested by the user (PEP 376’s REQUESTED file) The new dependency resolver is *off by default* because it is *not yet ready for everyday use*. The new dependency resolver is significantly stricter and more consistent when it receives incompatible instructions, and reduces support for certain kinds of constraints files, so some workarounds and workflows may break. Please test it with the --use-feature=2020-resolver flag. Please see our guide on how to test and migrate, and how to report issues <https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-res…>. We are preparing to change the default dependency resolution behavior and make the new resolver the default in pip 20.3 (in October 2020). This release also partially optimizes pip’s network usage during installation (as part of a Google Summer of Code project by McSinyx <https://summerofcode.withgoogle.com/projects/#5428041779511296>). Please test it with pip install --use-feature=fast-deps ... and report bugs to the issue tracker <https://github.com/pypa/pip/issues/new?template=bug-report.md>. This functionality is *still experimental* and *not ready for everyday use*. You can find more details (including deprecations and removals) in the changelog <https://pip.pypa.io/en/stable/news/>. 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) and to the Chan Zuckerberg Initiative <https://chanzuckerberg.com/eoss/> DAF, an advised fund of Silicon Valley Community Foundation, for their funding that enabled substantial work on the new resolver.

2 2

End of Travis-CI.org
by Sumana Harihareswara 21 Oct '20

21 Oct '20

Reminder: Travis-CI.org will be shut down on December 31, 2020: https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom?e=%5… If you still have packages that use Travis-CI.org (and I think some packaging projects do), now is the time to migrate them to Travis-CI.com. Migration instructions here: https://docs.travis-ci.com/user/migrate/open-source-repository-migration "We encourage you to migrate your existing repositories that are currently on travis-ci.org over to travis-ci.com as soon as possible, enabling you to identify any additional changes required to your code or configuration well in advance of the December 31st deadline." -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

1 0

Pip update fails
by brenners＠bezeqint.net 29 Sep '20

29 Sep '20

Hello, When I tried to install a package using pip, it informed me that there is a new version available. Per the recommendation, I tried to update pip, but the update failed. The following is the last few lines of the failure messages: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\scripts.py", line 386, in _get_launcher raise ValueError(msg) ValueError: Unable to find resource t64.exe in package pip._vendor.distlib WARNING: You are using pip version 20.2.2; however, version 20.2.3 is available. You should consider upgrading via the 'C:\Program Files\Python38\python.exe -m pip install --upgrade pip' command. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I can of course supply the full error traceback, if needed, not just these last few lines. The file: c:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\distlib\t64.exe DOES exist. I just installed the latest python version 3.8.6 – I would have thought it would already include the latest version of pip… Any help resolving this failure will be much appreciated.

2 1

happy diwali 2020
by sayedalam23＠yahoo.com 29 Sep '20

29 Sep '20

1 0

Unsubscribing from this list
by Paul Moore 21 Sep '20

21 Sep '20

I'm going to unsubscribe from this list, as it appears to be getting little but spam any more. I'll still be available on the Packaging topic on Discourse (https://discuss.python.org/c/packaging/14). To be honest, I think it's time to discontinue this list. But that's for others to decide. Paul

4 4

Failure: Error
by oliviajohn123123＠hotmail.com 21 Sep '20

21 Sep '20

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/

10 9

Yeh Rishta Kya Kehlata Hai
by kasautiki.com＠gmail.com 18 Sep '20

18 Sep '20

Thank you for posting such a great article! I found your website perfect for my needs. It contains wonderful and helpful posts. Keep up the good work!. Thank you for this wonderful Article! https://yehrishtakyakehlataserial.com/

1 0

pip install error
by Nourbakhsh Soltani, Zahrasadat 17 Sep '20

17 Sep '20

Helli I have problem upgrading pip. And afterward I cant even install any package in my interpreter. Here is the error Can you help me: Error: Traceback (most recent call last): File "C:\Program Files\JetBrains\PyCharm Community Edition 2019.2\helpers\packaging_tool.py", line 73, in run_pip runpy.run_module(module_name, run_name='__main__', alter_sys=True) File "C:\Users\ZSO\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 205, in run_module return _run_module_code(code, init_globals, run_name, mod_spec) File "C:\Users\ZSO\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 96, in _run_module_code mod_name, mod_spec, pkg_name, script_name) File "C:\Users\ZSO\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 85, in _run_code exec(code, run_globals) File "C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\__main__.py", line 19, in <module> sys.exit(_main()) File "C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\_internal\cli\main.py", line 73, in main command = create_command(cmd_name, isolated=("--isolated" in cmd_args)) File "C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\_internal\commands\__init__.py", line 96, in create_command module = importlib.import_module(module_path) File "C:\Users\ZSO\AppData\Local\Programs\Python\Python37\lib\importlib\__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1006, in _gcd_import File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 677, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 728, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\_internal\commands\install.py", line 24, in <module> from pip._internal.cli.req_command import RequirementCommand File "C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\_internal\cli\req_command.py", line 20, in <module> from pip._internal.operations.prepare import RequirementPreparer File "C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\_internal\operations\prepare.py", line 16, in <module> from pip._internal.distributions import ( File "C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\_internal\distributions\__init__.py", line 1, in <module> from pip._internal.distributions.source import SourceDistribution ImportError: cannot import name 'SourceDistribution' from 'pip._internal.distributions.source' (C:\Users\ZSO\PycharmProjects\111\venv\lib\site-packages\pip\_internal\distributions\source\__init__.py) Best regards Zahra

1 0

Leaving the list due to spam
by Brett Cannon 14 Sep '20

14 Sep '20

I just got two spam emails to this list. Looking at my archives there isn't much going on here and now spam is making up the majority of emails. So that hits my threshold for unsubscribing. See you all on discuss.python.org. :)

1 0

Free Premium APK MOD
by alltecloud＠yahoo.com 12 Sep '20

12 Sep '20

You can visit our website - https://alltechcloud.com and can mail here - alltecloud(a)yahoo.com

1 0

FYI: PEP 632: Deprecate distutils module
by Steve Dower 04 Sep '20

04 Sep '20

Hi distutils-sig Just wanted to let you know that I've proposed a core CPython PEP to formally deprecate and remove the standard library distutils module. Text and discussion at https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 The PEP has gone to python-dev formally because it only deals with the standard library module. setuptools, pip, and recent package work feature in the motivation, but are not bound to follow anything in this PEP. Cheers, Steve

1 0

appveyor failures
by Robin Becker 03 Sep '20

03 Sep '20

looking here for build expertise apologies if not suitable After a python source change one of my appveyor builds has started to fail compiling an extension. The previous build 28/August succeeded completely, but now I see a failure in the third sub-build. No change was made in the c source code. Python 2.7 X86 OK Python 2.7 AMD64 OK Python 3.5 X86 Fails compiling _renderPM.c at line 2150 > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -DRENDERPM_FT -DLIBART_COMPILATION -DLIBART_VERSION=\"2.3.21\" -Isrc\rl_addons\renderPM -Isrc\rl_addons\renderPM\libart_lgpl -Isrc\rl_addons\renderPM\gt1 -Iwinstuff\include\freetype2 -Ic:\Python35\include -Ic:\Python35\include -IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE -IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE -IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt -IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared -IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt /Tcsrc\rl_addons\renderPM\_renderPM.c /Fobuild\temp.win32-3.5\Release\src\rl_addons\renderPM\_renderPM.obj > _renderPM.c > src\rl_addons\renderPM\_renderPM.c(2150): error C2017: illegal escape sequence > src\rl_addons\renderPM\_renderPM.c(2150): error C2001: newline in constant > src\rl_addons\renderPM\_renderPM.c(2151): error C2143: syntax error: missing ')' before 'if' > error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\cl.exe' failed with the code there looks like this PyModule_AddObject(m, "_version", obj); obj = PyUnicode_FromString(LIBART_VERSION); /* this is line 2150 */ if(!obj)goto err; PyModule_AddObject(m, "_libart_version", obj); so it looks like the -DLIBART_VERSION=\"2.3.21\" is failing to pass stuff correctly. The Aug 28 build that worked perfectly used this command line > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -DRENDERPM_FT -DLIBART_COMPILATION -DLIBART_VERSION=\"2.3.21\" -Isrc\rl_addons\renderPM -Isrc\rl_addons\renderPM\libart_lgpl -Isrc\rl_addons\renderPM\gt1 -Iwinstuff\include\freetype2 -Ic:\Python35\include -Ic:\Python35\include "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt" /Tcsrc\rl_addons\renderPM\_renderPM.c /Fobuild\temp.win32-3.5\Release\src\rl_addons\renderPM\_renderPM.obj which looks identical. So it must be the environment/image. The build image is set at Visual Studio 2015. I tried using the previous image, but no luck there. Any ideas / advice welcome. Should I be using a stringify macro? -- Robin Becker

1 2

Kasauti Zindagi Ki
by Kazmi Bro 22 Aug '20

22 Aug '20

I like your post i got some good information thanks https://yehrishtakyakehlatahaiepisode.com/category/kasauti-zindagi-ki/

1 0

Yeh Rishta Kya Kehlata Hai
by Kazmi Bro 22 Aug '20

22 Aug '20

Hi, I really like you post and I was looking such information finally I got it many thanks for writing. <a href="https://yehrishtakyakehlatahaiepisode.com/"><strong>Yeh Rishta Kya Kehlata Hai</strong></a>

1 0

Thursday Aug 20th: short talk on PyPI & sustainability
by Sumana Harihareswara 13 Aug '20

13 Aug '20

Two researchers studied PyPI's sustainability to understand problems that affect FOSS infrastructure sustainability in general. On Thursday 20 Aug (2:30 - 3:45 PM EDT), one of the study's authors will speak in a Ford Foundation event about FOSS sustainability: https://www.eventbrite.com/e/digital-infrastructure-labor-roles-and-incenti… You can read the researchers' report at https://github.com/FOSSRIT/mismatches/blob/master/Mismatches%20Final%20repo… . Key section of the summary: > These results suggest that different strategies are needed for addressing the non-technical capacities of digital FOSS infrastructure projects. While capacity for things such as documentation, outreach, project management, design, legal work, etc. are often acknowledged as needs within FOSS communities at-large, they are rarely addressed proactively. Rather, they are often addressed only when a project is in crisis. I also draw your attention to the table of tensions between "FOSS culture" and "Infrastructure culture" on page 7, and the misperception that capacity-building may seem to be slowing a project down (p 6-7). (Disclosure: I was a consultant on this analysis.) -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

1 0

pip and missing shared system system library
by David Mathog 12 Aug '20

12 Aug '20

pip install package often results in compiling (using gcc, g++, whatever) to produce a binary. Usually that proceeds without issue. However, there seems to be no checking that the libraries required to link that binary are already on the system. Or at least the message which results when they are not is not at all clear about what is missing. I discovered that today by wasting several hours figuring out why scanpy-scripts was failing trying to build dependency "louvain", which would not install into a venv with pip. It had something to do with "igraph", but pip had downloaded python-igraph before it got to louvain. When louvain tried to build there was a mysterious message about pkgconfig and igraph Cannot find the C core of igraph on this system using pkg-config. (Note that when python-igraph installs it places an igraph directory in site-packages, so which it is referring to is fairly ambiguous.) Then it tried to install a different version number of igraph, failed, and the install failed. This was very confusing because the second igraph install was not (it turned out) a different version of python-igraph but a system level igraph library, which it could not install either because the process was not privileged and could not write to the target directories. Yet it tried to install anyway. This is discussed in the louvain documentation here (it turns out): https://github.com/vtraag/louvain-igraph but since I was actually trying to install a different package, of course I had not read the louvain documentation. In short form the problem was "cannot build a binary because required library libigraph.so is not present in the operating system" but that was less than obvious in the barrage of warnings and error messages. Is it possible to tell pip or setup.py to fail immediately when a required system library like this is not found, here presumably after that "C core" message, rather than confusing the matter further with a failed partial build and install of the same component? More generally, is there anything in the python installation methods which could list system libraries as dependencies and give a more informative error message when they are missing? Thanks, David Mathog

8 17

twine upload & network robustness
by Robin Becker 07 Aug '20

07 Aug '20

Because of covid-19 I am working a lot from home so my network is likely less robust. I was wondering about what happens if I upload with twine to pypi and halfway through my network fails. Is the uploaded filename remembered so I cannot retry when my network comes back? Or is the upload somehow atomic so that it has to complete(be checked) before the file is entered into pypi? -- Robin Becker

3 3

Best way for a project to provide an optional C module
by Daniele Varrazzo 03 Aug '20

03 Aug '20

Hello, packaging psycopg3, I'm wondering what is the best way to provide an optional optimisation module. 1) provide a separate psycopg3-c distribution 2) provide an extra psycopg3[c] 3) try building the extension and fail quietly. 1) seems the cleanest approach: the psycopg3 distribution would have no build-time external dependency (Cython, -dev packages, a compiler) and psycopg3-c can fail hard if some of these dependencies are missing. I am currently trying this approach, finding some problems in working out a good files layout to have two setup.py in the same git repository. 2) would be nice but I don't see a way to identify the extra requested at build time to implement a build_ext command such that if "c" is not the extra then don't do anything. it seems that extra are thought for a different use case, not for optional build-time parts 3) would give me endless headaches to work out why something failed, differentiate failures for missing dependencies from real errors, and dealing with user reports. What would be your advice? Press on with 1 or a different approach? Examples are welcome (the only one I have in mind is PyYAML doing 3). -- Daniele

3 3

Improving Communication
by Donald Stufft 30 Jul '20

30 Jul '20

Currently in the packaging space, we have a number of avenues for communication, which are: - distutils-sig - pypa-dev - virtualenv-users - Other project specific mailing lists - IRC - gitter - Various issue trackers spread across multiple platforms. - Probably more places I’m not remembering. The result of this is that all discussion ends up being super fractured amongst the various places. Sometimes that is exactly what you want (for instance, someone who is working on the wheel specs probably doesn’t care about deprecation policy and internal module renaming in pip) and sometimes that ends up being the opposite of what you want (for instance, when you’re describing something that touches PyPI, setuptools, flit, pip, etc all at once). Theoretically the idea is that distutils-sig is where cross project reaching stuff goes, IRC/gitter is where real time discussion goes, and the various project mailing lists and issue trackers are where the project specific bits go. The problem is that often times doesn’t actually happen in practice except for the largest and most obvious of changes. I think our current “communications stack” kind of sucks, and I’d love to figure out a better way for us to handle this that solves the sort of weird “independent but related” set of projects we have here. From my POV, a list of our major problems are: * Discussion gets fractured across a variety of platforms and locations, which can make it difficult to actually keep up with what’s going on but also to know how to loop in someone relevant if their input would be valuable. You have to more or less simultaneously know someone’s email, Github username, IRC nick, bitbucket username, etc to be able to bring threads of discussion to people’s attention. * It’s not always clear to users where a discussion should go, often times they’ll come to one location and need to get redirected to another location. If any discussion did happen in the incorrect location, it tends to need to get restarted in the new location (and depending on the specific platform, it may be impossible to actually redirect everyone over to the proper location, so you again, end up fractured with the discussion happening in two places). * A lot of the technology in this stack is particularly old, and lacks a lot of the modern day affordances that newer things have. An example is being able to edit a discussion post to fix typos that can hinder the ability of others to actually understand whats being talked about. In your typical mailing list or IRC there’s no mechanism by which you can edit an already sent message, so your only option is to either let the problem ride and hope it doesn’t trip up too many people, or send an additional message to correct the error. However these show up as additional, later messages which someone might not even see until they’ve already been thoroughly confused by the first message (since people tend to read email/IRC in a linear fashion). - There is a lot of things in this one, other things are things like being able to control in a more fine grained manner what email you’re going to get. - Holy crap, formatting and typography to make things actually readable and not a big block of plaintext. * We don’t have a clear way for users to get help, leaving users to treat random issues, discussion areas, etc as a support forum, rather than some place that’s actually optimized for that. Some of this ties back into some of the earlier things too, where it’s hard to actually redirect discussions These aren’t *new* problems, and often times the existing members of a community are the least effected becasue they’ve already spent effort learning the ins and outs and also curating a (typically custom) workflow that they’ve grown accustomed too. The problem with that is that often times that means that new users are left out, and the community gets smaller and smaller as time goes on as people leave and aren’t replaced with new blood, because they’re driven off but the issues with the stack. A big part of the place this is coming from, is me sitting back and realizing that I tend to be drawn towards pulling discussions into Github issues rather than onto the varying mailing lists, not because that’s always the most appropriate place for it, but because it’s the least painful place in terms of features and functionality. I figure if I’m doing that, when I already have a significant investment in setting up tooling and being involved here, that others (and particularly new users) are likely feeling the same way. - Donald

9 12

The Error NOT FOUND On My Project
by xelekid611＠mado34.com 25 Jul '20

25 Jul '20

I am facing the issue of not found "C:\Users\jaraco\projects\distutils_namespace\myns.projB\test\testBasic.py", can anyone guide me for this ? https://apkpalace.net/

1 0

Re: Fwd: Re: Use of "python" shebang an installation error?
by Filipe Laíns 22 Jul '20

22 Jul '20

On Tue, 2020-07-21 at 14:24 -0700, David Mathog wrote: > On Tue, Jul 21, 2020 at 2:03 PM Filipe Laíns <lains(a)archlinux.org> > wrote: > > On Tue, 2020-07-21 at 13:51 -0700, David Mathog wrote: > > > biopython-1.77, for instance, when installed into a virtualenv > > > with > > > pip3, has many of these shebangs: > > > > > > #!/usr/bin/env python > > > > > Is it being installed as an egg or wheel? Can you check what > > happens > > when you pass --use-pep517 to the pip install command (to force > > installing as a wheel)? > > > > It is wheel, it creates a directory > > biopython/lib/python3.6/site-packages/biopython-1.77.dist-info > > when installed either of these ways: > > pip3 install biopython > pip3 install biopython --use-pep517 > > Either way it has the same shebang in the files listed a few posts > up. > > Thanks, > > David Mathog You've fallen off-list again. The shebang handling for wheels is very well defined[1]. It looks like those shebangs come from biopython so it's their bug. No file a python package is supposed to be executed directly, so they shouldn't really have shebangs. The files that are superposed to be executed directly should be defined as scripts and have a #!python shebang so that the wheel installer can do its job properly. So unfortunately I think in most of the packages you are having issues with, the bug comes from the package upstream :/ [1] https://www.python.org/dev/peps/pep-0427/#recommended-installer-features Filipe Laíns

1 0

Fwd: Re: Use of "python" shebang an installation error?
by David Mathog 22 Jul '20

22 Jul '20

(oops, had to resend, forgot to change the destination to <distutils-sig(a)python.org>) On Mon, Jul 20, 2020 at 12:38 PM John Thorvald Wodder II <jwodder(a)gmail.com> wrote: > > On 2020 Jul 20, at 15:25, David Mathog <dmathog(a)gmail.com> wrote: > > Lately I have been working on a CentOS 8 machine, and it has "python2" > > and "python3", but no "python". Many packages install scripts with a > > shebang like: > > > > #!/usr/bin/env python > > > > and those do not work on this OS. Seems like rather a large missing > > dependency which goes by without triggering a fatal error. > > How exactly are these packages getting installed? Last time I checked, both pip and setuptools automatically set the shebang in scripts (both console_script entry points and scripts declared with the "scripts" argument to `setup()`) to use the path of the running Python interpreter. Are these packages installed using your system package manager? If so, you should take the problem up with its maintainers. Good point, I have been installing so many packages I get confused about which installer was used for which package. It turned out that many (but not all) of the files which contained #!/usr/bin/env python shebangs were installed using standard OS level tools (cmake, configure, make and the like). Example package, hisat2. I guess there isn't much choice for those but to scan the directories for python scripts and fix the shebangs. Installs that are initially into venvs and used pip3 are still an issue. Example: python3 -m venv johnnydep cd johnnydep grep -r '/usr/bin/env python$' . #finds: ./lib/python3.6/site-packages/pip/_vendor/appdirs.py:#!/usr/bin/env python ./lib/python3.6/site-packages/pip/_vendor/chardet/cli/chardetect.py:#!/usr/bin/env python ./lib/python3.6/site-packages/pip/_vendor/requests/certs.py:#!/usr/bin/env python ./lib/python3.6/site-packages/pkg_resources/_vendor/appdirs.py:#!/usr/bin/env python ./lib/python3.6/site-packages/johnnydep/pipper.py:#!/usr/bin/env python cd bin ls -1 | grep python lrwxrwxrwx. 1 modules modules 7 Jul 20 14:09 python -> python3 lrwxrwxrwx. 1 modules modules 16 Jul 20 14:09 python3 -> /usr/bin/python3 source activate pip3 install johnnydep head -1 johnnydep #!/home/common/lib/python3.6/Envs/johnnydep/bin/python #same for "tabulate" and all other shebangs in bin. cd .. grep -r '/usr/bin/env python$' . #same as before grep -r '/home/common/lib/python3.6/Envs/johnnydep/bin/python' . #just the files in the bin directory. It looks like none of the "#!/usr/bin/env python" shebangs within the venv are going to be used after the install, so perhaps those are harmless. The shebangs like #!/home/common/lib/python3.6/Envs/johnnydep/bin/python are OK within the venv, but once they are "devirtualized" they become a problem. That was a known problem though - my devirtualizer code already patches all of the ones in the bin directory. I have not seen any elsewhere (yet) within the venv, but there is probably no rule that keeps them from appearing in "share" or elsewhere. The "python" in use in the venv is just a symbolic link to "python3" which is itself a symbolic link to the actual program "/usr/bin/python3". It is constructed that way based on "python -m venv" which uses pieces which come from the CentOS 8 python3-libs-3.6.8-23.el8.x86_64 RPM. Is there some requirement that a venv have a "python"? Odd that RedHat (and so CentOS) provide a "python" there, but not in the OS itself. Thanks, David Mathog

6 8

Fwd: Re: Use of "python" shebang an installation error?
by David Mathog 21 Jul '20

21 Jul '20

(oops, had to resend, forgot to change the destination to <distutils-sig(a)python.org>) biopython-1.77, for instance, when installed into a virtualenv with pip3, has many of these shebangs: #!/usr/bin/env python And they are all over the place. They are: ./site-packages/Bio/bgzf.py: ./site-packages/Bio/PDB/parse_pdb_header.py: ./site-packages/Bio/PDB/PDBList.py: ./site-packages/Bio/Restriction/__init__.py: ./site-packages/Bio/Restriction/Restriction.py: ./site-packages/Bio/Restriction/PrintFormat.py: ./site-packages/Bio/Restriction/Restriction_Dictionary.py: ./site-packages/Bio/Wise/__init__.py: ./site-packages/Bio/Wise/psw.py: ./site-packages/Bio/Wise/dnal.py: ./site-packages/Bio/UniProt/GOA.py: ./site-packages/Bio/SeqUtils/__init__.py: Regards, David Mathog

2 1

Fwd: Re: Use of "python" shebang an installation error?
by David Mathog 21 Jul '20

21 Jul '20

On Mon, Jul 20, 2020 at 4:40 PM John Thorvald Wodder II <jwodder(a)gmail.com> wrote: > > First of all, your last two messages only went to me, not to the list. The mailing list doesn't set Reply-To on messages or the like, so you have to manually set "To: distutils-sig(a)python.org" when replying. Aargh, right. I use gmail for my home mail, and since I'm stuck working at home, that is what I used here. Gmail likes to hide, well, pretty much everything. I will repost those responses. > > As to your e-mail, though, are any of those files even meant to be executed? They're not in bin/; they just appear to be regular source files that some developer slapped a shebang on. That in a sense is the issue. I don't know, you don't know, maybe the developer knows (if he/she still remembers). I really don't want to do the work to dig through the code for every package I install to determine if a shebang is used or not. Yet if I don't figure this out some end user will run a script (one of a hundred in some package I installed for their use) which will blow up because of this issue. The best I can do now is run pdvctrl reshebang $TARGET_DIR or pdvctrl reshebang $ROOT_DIR... and fix them up after the fact. (pdvctrl from python_devirtualizer here: https://sourceforge.net/projects/python-devirtualizer/). Even then it usually has to guess that "python" means "python3" and not "python2", and sometimes it guesses wrong. Today's version of that recurring issue: https://github.com/lastz/lastz/issues/30 Regards, David Mathog

1 0

pip install very slow
by Stuart McGraw 21 Jul '20

21 Jul '20

Hello, First time trying to use Python's package tools and I'm attempting to use pip to install from a local project: python3 -m pip install --user --upgrade --no-deps ./ I have a simple directory structure very similar to that recommended in https://packaging.python.org/tutorials/packaging-projects/ project/ data/ mypackage/ __init__.py data/ *.csv module1.py module2.py tmpl/ *.jinja setup.py The project/data/ directory contains several GB of stuff I use during development. It is not supposed to be part of the package and it is not mentioned in setup.py. The problem is when I run the install command above it takes many minutes to finish. When I move the project/data/ sub-directory out of the project/ directory, it takes a few seconds. I thought perhaps that "packages=setuptools.find_packages()" in my setup.py file might be the culprit but replacing in with "packages=['mypackage']" made no difference. I'm not sure why pip seems to be roaming through project/data/ (if that's what's happening) but is there some way to get it not to? My apologies if this is covered in the docs somewhere; I'm still going though them but didn't see anything with an initial scan. If it helps, here is my setup.py file: setuptools.setup ( name="mypackage", version="...", author="Me", author_email="...", description="...", long_description="...", long_description_content_type="text/markdown", url="...", packages=['mypackage'], package_data={'mypackage': ['data/*.csv', 'tmpl/*.jinja',]}, zip_safe = False, classifiers=[...], python_requires='>=3.6', install_requires = ['jinja2',], ) Thanks for any enlightenment.

4 5

Use of "python" shebang an installation error?
by David Mathog 20 Jul '20

20 Jul '20

Lately I have been working on a CentOS 8 machine, and it has "python2" and "python3", but no "python". Many packages install scripts with a shebang like: #!/usr/bin/env python and those do not work on this OS. Seems like rather a large missing dependency which goes by without triggering a fatal error. In bioinformatics pipelines it is common for one package to invoke a script from another. So while the package which supplied a particular script might have avoided this issue by only invoking it with: python3 path/script that does not prevent another package from doing one of these: A path/script B python path/script In terms of analysis, it is trivial to find all python scripts installed by a package and examine the shebang line (if present) to see if this is an issue. I am adding a "reshebang" function to my python_devirtualizer specifically to handle the issue for scripts which are invoked directly. It is, however, not at all trivial to analyze all a package's code to see which scripts are called by other scripts, and how they are called. Moreover, they might be called from perl, or C, or some other language. So dealing with "B" above is not trivial. So, my question is, should the use of "python" (as opposed to "python2" or "python3") in a shebang be considered an installation error on a system for which "python" does not exist? I would argue yes, because we already know that python3 was not fully backwards compatible with python2, so we have reason to suspect that python4 (whenever that appears) might also not be fully backwards compatible with python3. By being picky about the python version now, that should prevent a lot of problems later. Regards, David Mathog

2 1

FASTEN and dependency analysis at call graph level
by Sumana Harihareswara 16 Jul '20

16 Jul '20

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/Introduction https://www.fasten-project.eu/view/Main/Overview https://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

3 2

Setuptools adopts distutils
by Jason R. Coombs 13 Jul '20

13 Jul '20

I’m pleased to announce the release of Setuptools 48, which adopts the distutils codebase from CPython per pypa/setuptools#417<https://github.com/pypa/setuptools/issues/417> and pypa/packaging-problems#127<https://github.com/pypa/packaging-problems/issues/127>. Given the amount of change this effort involved, it’s likely unstable and thus the major version bump. Please report issues at the Setuptools issue tracker. I’ll be around today (IRC, Gitter, Slack) to either disable the functionality or add an escape hatch if needed.

6 6

PEP 541 / Transfer of https://pypi.org/project/Augur/ to my project https://github.com/chaoss/augur
by Sean Goggins 08 Jul '20

08 Jul '20

Hi, I am the code owner for the Augur Open Source Software project, which is part of the Linux Foundation’s CHAOSS Project. One of my developers secured our PiPy distribution a few years ago, but deleted their account before graduating. I’m hoping to secure it again: https://pypi.org/project/Augur/ <https://pypi.org/project/Augur/> Our project is at https://github.com/chaoss/augur and is part of the Linux Foundation’s CHAOSS Project at https://chaoss.community Thanks! Sean P. Goggins Associate Professor, Computer Science University of Missouri http://www.seangoggins.net <http://www.seangoggins.net/> visit: http://www.augurlabs.io <http://www.augurlabs.io/> (Research Lab) [Sloan Foundation, National Science Foundation] visit: http://www.globalconsentmanager.com <http://www.globalconsentmanager.com/> (Privacy Research) (Reynolds Journalism Institute and Mozilla) visit: <http://mhs.missouri.edu/>http://mhs.missouri.edu <http://mhs.missouri.edu/> (for mission hydro sci!) [i3 & IES] visit: http://www.sociotech.net <http://www.sociotech.net/> visit: <http://chaoss.community/> <http://chaoss.community/> <http://chaoss.community/>http://c <http://c/>haoss.community (for open source health metrics) [Sloan Foundation] visit: http://sociallycompute.io <http://sociallycompute.io/> (for code like things and Group Informatics) [National Science Foundation] “You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space.” -- Johnny Cash

3 2

package management - common storage while keeping the versions straight
by David Mathog 08 Jul '20

08 Jul '20

Hi all, First post here. I have a cluster where the common software is NFS shared from the file server to other nodes. All the python packages are kept in a directory which is referenced by PYTHONPATH. The good part of that is that there is just one copy of each package-version. The bad part, as you have all no doubt guessed, is that python by itself is really bad at specifying and loading a set of particular library versions (see below), so upgrading one program will break another due to conflicting installed versions. Hence the common use of virtualenv's. But as far as I can tell each virtualenv installs a copy of each package-version it needs, resulting in multiple copies of the same package-version for common packages on the same disk. What I am after is some method of keeping exactly one copy of each package-version in the common area (ie, one might find foo-1.2, foo-1.7, and foo-2.3 there), while also presenting only the one version of each (let's say foo-1.7) to a particular installed program. On linux it might do that by making soft links to the common PYTHONPATH area from another directory for which it sets PYTHONPATH for the application. Finally, this has to be usable by any account which has read execute access to the main directory. Does such a beast exist? If so, please point me to it! The limitations of python version handling to which I refer above can be illustrated for "scanpy-scripts"'s dependencies. Given all the needed libraries in one place (plus incompatible versions) the right set can be loaded (and verified) like this: export PYTHONPATH=/path/to_common_area python3 __requires__ = ['scipy <1.3.0,>=1.2.0', 'anndata <0.6.20', 'loompy <3.0.0,>=2.00', 'h5py <2.10'] import pkg_resources import scipy import anndata import loompy import h5py import scanpy print(scipy.__version__) print(anndata.__version__) print(loompy.__version__) print(h5py.__version__) print(scanpy.__version__) quit() which emits exactly the versions scanpy-scripts needs: 1.2.3 0.6.19 2.0.17 2.9.0 1.4.3 However, adding , 'scanpy <1.4.4,>=1.4.2' at the end of __requires__ makes the whole thing fail at import pkg_resources with (many lines deleted) 792, in resolve raise VersionConflict(dist, req).with_context(dependent_req) pkg_resources.ContextualVersionConflict: (scipy 1.2.3 (/home/common/lib/python3.6/site-packages/scipy-1.2.3-py3.6-linux-x86_64.egg), Requirement.parse('scipy>=1.3.1'), {'umap-learn'}) even though the scanpy it loaded in the first case was within the desired range. Moreover, specifying the desired versions as parameters to import pkg_resources does not work at all since pkg_resources only keeps the highest version of each package it finds when imported. (A limitation that never made the least bit of sense to me.) The test system is CentOS 8 with python 3.6.8. Thanks, David Mathog

6 18

Development installation with pyproject.toml/poetry?
by fredrik＠averpil.com 01 Jul '20

01 Jul '20

Hi, I have converted my setup.py to pyproject.toml and use poetry to build/manage deps. I maintain packages which also have dependency packages and I frequently use development installations locally ("pip install -e ../my-dep") so to develop dependencies at the same time as my main packages. Q: With a pyproject.toml, can I enable some sort of development installation without also maintaining a setup.py - or is there a plan/PEP for enabling this without a setup.py? Right now, I have a setup.py which needs to stipulate a number of things which is already in my pyproject.toml. In particular, I find it a little bothering that I need to specify the entry_points/console_scripts in both the pyproject.toml and in setup.py. Kind regards, Fredrik

4 3

setup.py with a different name
by Gabriel Becedillas 30 Jun '20

30 Jun '20

Hi, I'm trying to build a python package but my setup.py is actually named pkg1_setup.py (this is because I have multiple packages in the same repo). The package built is *almost* fine, except that setup.py is not included in the package built. I understand that the *normal* structure would be to have something like this: * setup.py * mypackage\... but before refactoring the repository structure to accommodate that I'd like to validate that there is no other way of doing that. I tried using the script_name parameter to setuptools.setup but had no luck. Any suggestions? Thanks a lot

2 1

ANN: distlib 0.3.1 released on PyPI
by Vinay Sajip 28 Jun '20

28 Jun '20

I've recently released version 0.3.1 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: * Fixed #132: Added documentation to help with relative interpreter paths. Thanks to Paul Kienzle for the patch. * Fixed #134: Allowed specifying a different target Python version when generating scripts. * Fixed #135: Exposed the ``enquote_executable`` function previously implemented as an internal function. * Addressed #138: Improved metadata support for newer metadata versions. Thanks to James Tocknell for the patch. * Changed the output of flags in entry point definitions in wheels. Thanks to frostming (明希) for the patch. * Stopped writing JSON metadata. Only old-style metadata is written now. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Note: Mailman3 might mishandle some of the links below. In that case, just copy and paste the links into your browser address bar - that should work. Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.1/ [2] https://distlib.readthedocs.io/en/0.3.1/ [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

Re: package management - common storage while keeping the versions straight
by Jason Madden 25 Jun '20

25 Jun '20

On Tue, 2020-06-23 at 15:51 -0700, David Mathog wrote: > What I am after is some method of keeping exactly one copy of each > package-version in the common area (ie, one might find foo-1.2, > foo-1.7, and foo-2.3 there), while also presenting only the one > version of each (let's say foo-1.7) to a particular installed program. > On linux it might do that by making soft links to the common > PYTHONPATH area from another directory for which it sets PYTHONPATH > for the application. Finally, this has to be usable by any account > which has read execute access to the main directory. > > Does such a beast exist? If so, please point me to it! zc.buildout[1] and zc.recipe.egg[2] can do something very much like this. zc.buildout tries hard to maintain reproducibility and isolation, and one of the ways it does this is by keeping each package in its own .egg directory. It then generates the entry-point scripts and a REPL with ``sys.path`` explicitly set to reference exactly the versions specified. There's no virtualenv-like activation step that puts all those scripts on the path, though, so one must either do that manually or just invoke the generated scripts directly. For example, here's a buildout configuration that specifies a shared directory to store eggs in. It also has some parts using zc.recipe.egg, one that will use zope.interface 4 and one that will use zope.interface 5 (egg specifications can be arbitrarily complex, of course, dependencies are followed, etc): [buildout] eggs-directory = /<path>/buildout-eggs abi-tag-eggs = true parts = old-interface new-interface new-interface-plus [old-interface] recipe = zc.recipe.egg eggs = zope.interface == 4.0 interpreter = old-py [new-interface] recipe = zc.recipe.egg eggs = zope.interface == 5.1 interpreter = new-py [new-interface-plus] recipe = zc.recipe.egg eggs = zope.interface == 5.1 zope.component interpreter = new-py-plus After running `buildout`, I have three REPL files (if zope.interface had defined any entry point scripts, I could also have had those generated): $ head bin/new-py #!<path/to/python> import sys sys.path[0:0] = [ '/<path>/buildout-eggs/pypy_73/zope.interface-5.1.0-py2.7.egg', '/<path/to/python>/site-packages', ] $ head bin/old-py #!<path/to/python> import sys sys.path[0:0] = [ '/<path>/buildout-eggs/pypy_73/zope.interface-4.0.0-py2.7.egg', '/<path/to/python>/site-packages', ] $ head bin/new-py-plus #!<path/to/python> import sys sys.path[0:0] = [ '/<path>/buildout-eggs/pypy_73/zope.interface-5.1.0-py2.7.egg', '/<path>/buildout-eggs/pypy_73/zope.component-4.6.1-py2.7.egg', '/<path/to/python>/site-packages', ] I've got a collection of zope.interface eggs referenced from a variety of different buildouts (at least at one point in time) and from a variety of different Python implementations, but only ever one copy of each: $ ls -ld buildout-eggs/*/zope.interface* Permissions Size User Date Modified Name drwxr-xr-x - jmadden 2017-05-04 06:53 buildout-eggs/pypy_41/zope.interface-4.4.0-py2.7.egg/ drwxr-xr-x - jmadden 2017-05-04 07:00 buildout-eggs/cp27m/zope.interface-4.4.0-py2.7-macosx-10.12-x86_64.egg/ drwxr-xr-x - jmadden 2017-05-09 17:55 buildout-eggs/cp34m/zope.interface-4.4.0-py3.4-macosx-10.12-x86_64.egg/ drwxr-xr-x - jmadden 2017-06-08 10:20 buildout-eggs/cp27m/zope.interface-4.4.1-py2.7-macosx-10.12-x86_64.egg/ drwxr-xr-x - jmadden 2017-07-11 10:07 buildout-eggs/cp36m/zope.interface-4.4.2-py3.6-macosx-10.12-x86_64.egg/ drwxr-xr-x - jmadden 2017-12-08 11:10 buildout-eggs/cp27m/zope.interface-3.6.7-py2.7-macosx-10.13-x86_64.egg/ drwxr-xr-x - jmadden 2018-05-07 11:05 buildout-eggs/cp27m/zope.interface-4.1.3-py2.7-macosx-10.13-x86_64.egg/ drwxr-xr-x - jmadden 2020-03-13 07:53 buildout-eggs/cp27m/zope.interface-4.6.0-py2.7-macosx-10.15-x86_64.egg/ drwxr-xr-x - jmadden 2020-04-08 07:32 buildout-eggs/cp38/zope.interface-5.1.0-py3.8-macosx-10.15-x86_64.egg/ drwxr-xr-x - jmadden 2020-05-17 09:30 buildout-eggs/cp27m/zope.interface-5.1.0-py2.7.egg/ drwxr-xr-x - jmadden 2020-06-11 07:42 buildout-eggs/pypy_73/zope.interface-5.1.0-py2.7.egg/ drwxr-xr-x - jmadden 2020-06-25 11:58 buildout-eggs/pypy_73/zope.interface-4.0.0-py2.7.egg/ ~Jason [1] http://www.buildout.org/ ; I recommend version 3, which uses pip to find eggs [2] https://pypi.org/project/zc.recipe.egg/

1 0

Twine 3.2.0 released
by Brian Rutledge 24 Jun '20

24 Jun '20

https://pypi.org/project/twine/3.2.0/ Changelog: https://twine.readthedocs.io/en/latest/changelog.html This is my first release as a Twine maintainer. Thanks to: - Sumana Harihareswara for getting me started, and nudging me along the way - Ian Stapleton Cordasco, Jason R. Coombs, and Dustin Ingram for code review and guidance in general - Devesh Kumar Singh, Felipe Mulinari Rocha Campos, and Vikram Jayanthi for substantial contributions to this release

2 1

[PEP 508] Clarification of URL References
by w_minchin＠hotmail.com 23 Jun '20

23 Jun '20

PEP 508 allows for pointing to required packages using URL's. This is the except: A minimal URL based lookup:: pip @ https://github.com/pypa/pip/archive/1.3.1.zip#sha1=da9234ee9982d4bbb3c72346… However, there is very little documentation, blog posts, etc on how to use beyond the PEP itself, and so I struggled to understand it. I incorrectly assumed that *pip*, at the start of the line, had something to do with the given package being *installed via pip*, rather than *the name of the package being installed*. Therefore, is it possible to list another example line in the PEP to make it clear that the line doesn't have to start with "pip" to work? For further reading, my original issue, and the discovered solution --> https://github.com/jazzband/pip-tools/issues/1056 The explanation there that was helpful for me (that I didn't get from reading the PEP) was: > I believe the issue is in the name @ url pattern. It should be project_name @ vcs_url, no eggs param needed in this case by the way, but the project_name should be the same as package name in vcs_url/setup.py. [source](https://github.com/jazzband/pip-tools/issues/1056#issuecomment-5829… c.f. the issue I raised on GitHub, where I was suggested to post here --> https://github.com/python/peps/issues/1444 Thanks.

2 2

Who is approving PyPI size limit exceptions these days?
by Steve Dower 19 Jun '20

19 Jun '20

These issues seem to be awaiting approval: https://github.com/pypa/pypi-support/labels/limit%20request Most pressing (for me ;) ) is my colleagues at https://github.com/pypa/pypi-support/issues/457, who are already dealing with confused users not finding the packages they expect. Thanks, Steve

1 0

(no subject)
by Raregem Augustine 16 Jun '20

16 Jun '20

Hello! I have tried several times and it has not been working to install external packages in Python. I continue to get ERROR: Could not find a version that satisfies the requirement SomePackage (from versions: non) ERROR: No matching distribution found for SomePackage. Please, how can I fix this. Thank you.

2 1

Installing a module
by Rishi 16 Jun '20

16 Jun '20

2 1

Re: July 1 deadline for Mercurial repositories on Bitbucket
by Vinay Sajip 16 Jun '20

16 Jun '20

FYI distlib has moved to Git, while remaining on BitBucket. The move was made in January 2020. https://bitbucket.org/pypa/distlib/src/master/ Regards, Vinay Sajip On Tuesday, 16 June 2020, 03:45:52 BST, distutils-sig-request(a)python.org <distutils-sig-request(a)python.org> wrote: Send Distutils-SIG mailing list submissions to distutils-sig(a)python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman3/lists/distutils-sig.python.org/ or, via email, send a message with subject or body 'help' to distutils-sig-request(a)python.org You can reach the person managing the list at distutils-sig-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Distutils-SIG digest..." Today's Topics: 1. July 1 deadline for Mercurial repositories on Bitbucket (Sumana Harihareswara) 2. Re: July 1 deadline for Mercurial repositories on Bitbucket (Cooper Lees) 3. Re: July 1 deadline for Mercurial repositories on Bitbucket (Sumana Harihareswara) 4. Re: July 1 deadline for Mercurial repositories on Bitbucket (Sumana Harihareswara) ---------------------------------------------------------------------- Date: Mon, 15 Jun 2020 17:29:42 -0400 From: Sumana Harihareswara <sh(a)changeset.nyc> Subject: [Distutils] July 1 deadline for Mercurial repositories on Bitbucket To: DistUtils mailing list <distutils-sig(a)python.org> Message-ID: <372de837-9aa7-f489-bb42-0d3077ad50a7(a)changeset.nyc> Content-Type: text/plain; charset=utf-8; format=flowed TL;DR: distlib_hg and bandersnatch, you have a July 1st deadline to switch to Git or move off Bitbucket. https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket "we've decided to remove Mercurial support from Bitbucket Cloud and its API." "Mercurial features and repositories will be officially removed from Bitbucket and its API on July 1, 2020." Most of https://bitbucket.org/pypa/ is Mercurial repos. Maintainers of those repositories need to switch them to Git or move them off Bitbucket by July 1st. distlib_hg and bandersnatch are the active Mercurial repos that most clearly need to switch or move. A few repos in bitbucket.org/pypa have explicit "moved to GitHub" notices on them. And I assume its pkg_resources , setuptools, import_resources, pylauncher, and bootstrap projects are now defunct, but it's probably worth archiving them somehow anyway, for historical reference. -- Sumana Harihareswara Changeset Consulting https://changeset.nyc ------------------------------ Date: Mon, 15 Jun 2020 14:34:02 -0700 From: Cooper Lees <me(a)cooperlees.com> Subject: [Distutils] Re: July 1 deadline for Mercurial repositories on Bitbucket To: Sumana Harihareswara <sh(a)changeset.nyc> Cc: DistUtils mailing list <distutils-sig(a)python.org> Message-ID: <A8E14546-4C8C-45EE-9458-473E5A3D5BF5(a)cooperlees.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_108E09A8-924C-4637-B2BF-854F5C6C3608" --Apple-Mail=_108E09A8-924C-4637-B2BF-854F5C6C3608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bandersnatch moved over 2 years ago and has been displaying the move on = the repository this whole time via the README.md. I just deleted it from BitBucket. As we have been for the last 2 years, = all bandersnatch action can be found here: = https://github.com/pypa/bandersnatch = <https://github.com/pypa/bandersnatch> Cooper > On Jun 15, 2020, at 2:29 PM, Sumana Harihareswara <sh(a)changeset.nyc> = wrote: >=20 > TL;DR: distlib_hg and bandersnatch, you have a July 1st deadline to = switch to Git or move off Bitbucket. >=20 > https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket >=20 > "we've decided to remove Mercurial support from Bitbucket Cloud and = its API." >=20 > "Mercurial features and repositories will be officially removed from = Bitbucket and its API on July 1, 2020." >=20 > Most of https://bitbucket.org/pypa/ is Mercurial repos. Maintainers of = those repositories need to switch them to Git or move them off Bitbucket = by July 1st. >=20 > distlib_hg and bandersnatch are the active Mercurial repos that most = clearly need to switch or move. >=20 > A few repos in bitbucket.org/pypa have explicit "moved to GitHub" = notices on them. And I assume its pkg_resources , setuptools, = import_resources, pylauncher, and bootstrap projects are now defunct, = but it's probably worth archiving them somehow anyway, for historical = reference. >=20 > --=20 > Sumana Harihareswara > Changeset Consulting > https://changeset.nyc > -- > Distutils-SIG mailing list -- distutils-sig(a)python.org > To unsubscribe send an email to distutils-sig-leave(a)python.org > https://mail.python.org/mailman3/lists/distutils-sig.python.org/ > Message archived at = https://mail.python.org/archives/list/distutils-sig@python.org/message/QOS= UVOF6RY4EVFBFZRHL4WAENXVKH5YL/ --Apple-Mail=_108E09A8-924C-4637-B2BF-854F5C6C3608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" = class=3D"">Bandersnatch moved over 2 years ago and has been displaying = the move on the repository this whole time via the README.md.<div = class=3D""><br class=3D""></div><div class=3D"">I just deleted it from = BitBucket. As we have been for the last 2 years, all bandersnatch action = can be found here: <a href=3D"https://github.com/pypa/bandersnatch" = class=3D"">https://github.com/pypa/bandersnatch</a><div class=3D""><br = class=3D""></div><div class=3D"">Cooper<br class=3D""><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Jun = 15, 2020, at 2:29 PM, Sumana Harihareswara <<a = href=3D"mailto:sh@changeset.nyc" class=3D"">sh(a)changeset.nyc</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">TL;DR: distlib_hg and bandersnatch, you have a July 1st = deadline to switch to Git or move off Bitbucket.<br class=3D""><br = class=3D""><a = href=3D"https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbuck= et" = class=3D"">https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitb= ucket</a><br class=3D""><br class=3D"">"we've decided to remove = Mercurial support from Bitbucket Cloud and its API."<br class=3D""><br = class=3D"">"Mercurial features and repositories will be officially = removed from Bitbucket and its API on July 1, 2020."<br class=3D""><br = class=3D"">Most of https://bitbucket.org/pypa/ is Mercurial repos. = Maintainers of those repositories need to switch them to Git or move = them off Bitbucket by July 1st.<br class=3D""><br class=3D"">distlib_hg = and bandersnatch are the active Mercurial repos that most clearly need = to switch or move.<br class=3D""><br class=3D"">A few repos in = bitbucket.org/pypa have explicit "moved to GitHub" notices on them. And = I assume its pkg_resources , setuptools, import_resources, pylauncher, = and bootstrap projects are now defunct, but it's probably worth = archiving them somehow anyway, for historical reference.<br class=3D""><br= class=3D"">-- <br class=3D"">Sumana Harihareswara<br class=3D"">Changeset= Consulting<br class=3D"">https://changeset.nyc<br class=3D"">--<br = class=3D"">Distutils-SIG mailing list -- distutils-sig(a)python.org<br = class=3D"">To unsubscribe send an email to = distutils-sig-leave(a)python.org<br = class=3D"">https://mail.python.org/mailman3/lists/distutils-sig.python.org= /<br class=3D"">Message archived at = https://mail.python.org/archives/list/distutils-sig@python.org/message/QOS= UVOF6RY4EVFBFZRHL4WAENXVKH5YL/<br = class=3D""></div></div></blockquote></div><br = class=3D""></div></div></body></html>= --Apple-Mail=_108E09A8-924C-4637-B2BF-854F5C6C3608-- ------------------------------ Date: Mon, 15 Jun 2020 17:39:27 -0400 From: Sumana Harihareswara <sh(a)changeset.nyc> Subject: [Distutils] Re: July 1 deadline for Mercurial repositories on Bitbucket To: Cooper Lees <me(a)cooperlees.com> Cc: DistUtils mailing list <distutils-sig(a)python.org> Message-ID: <89166584-3008-dc33-df51-9ed53a9814cd(a)changeset.nyc> Content-Type: text/plain; charset=windows-1252; format=flowed Sorry I missed the note on the README! On 6/15/20 5:34 PM, Cooper Lees wrote: > Bandersnatch moved over 2 years ago and has been displaying the move on > the repository this whole time via the README.md. > > I just deleted it from BitBucket. As we have been for the last 2 years, > all bandersnatch action can be found here: > https://github.com/pypa/bandersnatch <https://github.com/pypa/bandersnatch> > > Cooper > >> On Jun 15, 2020, at 2:29 PM, Sumana Harihareswara <sh(a)changeset.nyc >> <mailto:sh@changeset.nyc>> wrote: >> >> TL;DR: distlib_hg and bandersnatch, you have a July 1st deadline to >> switch to Git or move off Bitbucket. >> >> https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket >> <https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket> >> >> "we've decided to remove Mercurial support from Bitbucket Cloud and >> its API." >> >> "Mercurial features and repositories will be officially removed from >> Bitbucket and its API on July 1, 2020." >> >> Most of https://bitbucket.org/pypa/ is Mercurial repos. Maintainers of >> those repositories need to switch them to Git or move them off >> Bitbucket by July 1st. >> >> distlib_hg and bandersnatch are the active Mercurial repos that most >> clearly need to switch or move. >> >> A few repos in bitbucket.org/pypa have explicit "moved to GitHub" >> notices on them. And I assume its pkg_resources , setuptools, >> import_resources, pylauncher, and bootstrap projects are now defunct, >> but it's probably worth archiving them somehow anyway, for historical >> reference. >> >> -- >> Sumana Harihareswara >> Changeset Consulting >> https://changeset.nyc >> -- >> Distutils-SIG mailing list -- distutils-sig(a)python.org >> To unsubscribe send an email to distutils-sig-leave(a)python.org >> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ >> Message archived at >> https://mail.python.org/archives/list/distutils-sig@python.org/message/QOSU… > ------------------------------ Date: Mon, 15 Jun 2020 22:43:20 -0400 From: Sumana Harihareswara <sh(a)changeset.nyc> Subject: [Distutils] Re: July 1 deadline for Mercurial repositories on Bitbucket To: Cooper Lees <me(a)cooperlees.com> Cc: DistUtils mailing list <distutils-sig(a)python.org> Message-ID: <2b9c15d2-ac7d-ffaa-43ac-b2645a6f3bc3(a)changeset.nyc> Content-Type: text/plain; charset=utf-8; format=flowed I also just looked more closely at https://bitbucket.org/pypa/distlib_hg/src/default/ and https://bitbucket.org/pypa/distlib/src/master/ . The latter is a Git port of the former. So I still think it would be a very good idea to export and archive the old version history, issues, etc. for the Mercurial distlib repo, but it's less crucial. On 6/15/20 5:39 PM, Sumana Harihareswara wrote: > Sorry I missed the note on the README! > > On 6/15/20 5:34 PM, Cooper Lees wrote: >> Bandersnatch moved over 2 years ago and has been displaying the move >> on the repository this whole time via the README.md. >> >> I just deleted it from BitBucket. As we have been for the last 2 >> years, all bandersnatch action can be found here: >> https://github.com/pypa/bandersnatch >> <https://github.com/pypa/bandersnatch> >> >> Cooper >> >>> On Jun 15, 2020, at 2:29 PM, Sumana Harihareswara <sh(a)changeset.nyc >>> <mailto:sh@changeset.nyc>> wrote: >>> >>> TL;DR: distlib_hg and bandersnatch, you have a July 1st deadline to >>> switch to Git or move off Bitbucket. >>> >>> https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket >>> <https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket> >>> >>> "we've decided to remove Mercurial support from Bitbucket Cloud and >>> its API." >>> >>> "Mercurial features and repositories will be officially removed from >>> Bitbucket and its API on July 1, 2020." >>> >>> Most of https://bitbucket.org/pypa/ is Mercurial repos. Maintainers >>> of those repositories need to switch them to Git or move them off >>> Bitbucket by July 1st. >>> >>> distlib_hg and bandersnatch are the active Mercurial repos that most >>> clearly need to switch or move. >>> >>> A few repos in bitbucket.org/pypa have explicit "moved to GitHub" >>> notices on them. And I assume its pkg_resources , setuptools, >>> import_resources, pylauncher, and bootstrap projects are now defunct, >>> but it's probably worth archiving them somehow anyway, for historical >>> reference. >>> >>> -- >>> Sumana Harihareswara >>> Changeset Consulting >>> https://changeset.nyc >>> -- >>> Distutils-SIG mailing list -- distutils-sig(a)python.org >>> To unsubscribe send an email to distutils-sig-leave(a)python.org >>> https://mail.python.org/mailman3/lists/distutils-sig.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/distutils-sig@python.org/message/QOSU… >>> >> > -- > Distutils-SIG mailing list -- distutils-sig(a)python.org > To unsubscribe send an email to distutils-sig-leave(a)python.org > https://mail.python.org/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/archives/list/distutils-sig@python.org/message/N5QX… > ------------------------------ Subject: Digest Footer -- Distutils-SIG mailing list -- distutils-sig(a)python.org To unsubscribe send an email to distutils-sig-leave(a)python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ ------------------------------ End of Distutils-SIG Digest, Vol 206, Issue 1 *********************************************

1 0

July 1 deadline for Mercurial repositories on Bitbucket
by Sumana Harihareswara 16 Jun '20

16 Jun '20

TL;DR: distlib_hg and bandersnatch, you have a July 1st deadline to switch to Git or move off Bitbucket. https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket "we've decided to remove Mercurial support from Bitbucket Cloud and its API." "Mercurial features and repositories will be officially removed from Bitbucket and its API on July 1, 2020." Most of https://bitbucket.org/pypa/ is Mercurial repos. Maintainers of those repositories need to switch them to Git or move them off Bitbucket by July 1st. distlib_hg and bandersnatch are the active Mercurial repos that most clearly need to switch or move. A few repos in bitbucket.org/pypa have explicit "moved to GitHub" notices on them. And I assume its pkg_resources , setuptools, import_resources, pylauncher, and bootstrap projects are now defunct, but it's probably worth archiving them somehow anyway, for historical reference. -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

2 3

setup() arguments documentation
by Johannes Müller 02 Jun '20

02 Jun '20

Hi, Shouldn't it be documented that the keyword argument "license_file" is supported as an agrument in setup()? It's currently not listed in the section https://setuptools.readthedocs.io/en/latest/setuptools.html#new-and-changed… Writing setup(..., license_file="LICENSE.txt", ...) has actually the same effect as adding "license_file" to the metadata section of setup.cfg. Such an elementary functionality as adding a license_file to a package should be considered to be a standard functionality of setup(), that should be properly documented. Right now, the users get's the impression, that it's necessary to use a setup.cfg file, if they want to use the license_file property. Regards, Johannes

1 0

Announcement: Pipenv Beta Release
by Dan Ryan 28 May '20

28 May '20

Greetings all! I am happy to announce that after a long hiatus, there is a pre-release of pipenv available for testing. You can read the full announcement at https://discuss.python.org/t/announcement-pipenv-beta-release/4051 I look forward to your feedback. Thanks, Dan -- Dan Ryan Software Engineer | Pipenv Maintainer Canonical, Ltd. | Python Packaging Authority dan.ryan(a)canonical.com | dan(a)danryan.co

3 3

Announcement: pip 20.2b1 release
by Paul Moore 21 May '20

21 May '20

A new beta release of pip, 20.2b1 has been released! You can install it by running `python -m pip install --upgrade --pre pip`. This release is mainly intended for users interested in testing the new resolver code (available via the `--unstable-feaure=resolver` option to pip). Apart from the resolver, there are only a couple of changes over the current stable (20.1.1) release of pip. However, as we move closer to having a feature-complete release of the new resolver, we wanted to provide an updated snapshot of the new resolver functionality, to allow people interested in helping us with the testing to get access to the latest changes that have been made. Thanks to everyone who has contributed to this release, and in particular to all of the people who have tested and provided feedback on the new resolver so far! On behalf of the pip maintainers, Paul Moore

1 0

pip UX studies: Test pip's new resolver and help us document dependency conflicts
by Bernard Tyers - Sane UX Design 21 May '20

21 May '20

Hi there, It's Bernard and Nicole from the pip Team. The team is working on the improving the way that pip resolves package dependency conflicts. We're asking for your help to test pip's new resolver. We're especially interested in hearing from people who have projects with complex dependencies. By complex dependencies we mean projects that look like this: - have at least 10 package dependencies - some package are pinned to specific versions - that you always have a dependency issue when installing it - you have to put in hacks, workarounds, or fixes Currently, we’re trying to discover all the ways in which pip‘s dependency resolver fails, so that we can work out what error messages and/or debugging information we should display. You can find out what we'd like you to do on this blog post: http://www.ei8fdb.org/thoughts/2020/05/test-pips-alpha-resolver-and-help-us… If you're into social media, we'd appreciate if you'd boost these messages too: https://twitter.com/nlhkabu/status/1263132447971172352 https://social.ei8fdb.org/@bernard/104205537250874117 You can sign-up for other UX Studies also: http://www.ei8fdb.org/thoughts/2020/03/pip-ux-study-recruitment/ If you've got any questions, reply here off or on-list. Thanks, Bernard & Nicole pip Team UX -- Bernard Tyers, User research & Interaction Design Sane UX Design Twitter: @bernardtyers PGP Key: keybase.io/ei8fdb I am currently working with the Python Foundation, and Open Technology Fund

1 0

Fwd: [tuf] TUF Community Meeting
by Sumana Harihareswara 20 May '20

20 May '20

Heads-up if you are interested in PyPI's implementation of TUF. -------- Forwarded Message -------- Subject: [tuf] TUF Community Meeting Date: Wed, 20 May 2020 09:58:05 -0700 From: Marina Moore To: theupdateframework@g....com Hello, The next TUF community meeting will be Wednesday May 27 at 10am ET at https://meet.jit.si/TUFCommunityMeeting <https://meet.jit.si/TUFCommunityMeeting>. Please let me know if there is anything you would like to discuss with the TUF community or if you have any questions. A draft agenda is available at https://hackmd.io/jdAk9rmPSpOYUdstbIvbjw <https://hackmd.io/jdAk9rmPSpOYUdstbIvbjw> and will be updated as more agenda items are proposed. I hope to see you there. Thanks, Marina -- You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group..... To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/CAMyDYMeykSshKwBh-g6_R… <https://groups.google.com/d/msgid/theupdateframework/CAMyDYMeykSshKwBh-g6_R…>.

1 0

invoking pep 540 -X utf8 for a console_script?
by Philip Austin 19 May '20

19 May '20

The https://executablebooks.org project has a jupyter-book excutable that wraps sphinx via a console_script. We'd like to ensure UTF8 everywhere when windows users run that script. Would be grateful for a pointer on how best to accomplish this.

1 0

Installing Python Modules
by Thory Coquillo 13 May '20

13 May '20

Hello, I'm using the current version of Python on both a MacBook Pro and an iMac. I'm trying to import the pygame module from the terminal. The problem is that it's applying the module to Python 2.7 that came with the computer. Is there a way that I can correct the path so that every command I enter in the Terminal gets applied to whichever current version of Python that I'm running? Let me know. Thanks, Thory

3 3

How should virtualenv handle the seed pip version
by Bernat Gabor 10 May '20

10 May '20

Please vote (and share your thoughts) on how you think virtualenv should handle what pip you get by default on new virtual environment creation: https://discuss.python.org/t/how-should-virtualenv-behave-respective-of-see… Thanks, Bernat

1 0

Top 5 Verified Millionaire Dating Sites Reviews in 2020
by broadjulongsoft＠gmail.com 04 May '20

04 May '20

Verified millionaire dating sites can help you choose the right dating website to meet a rich man or beautiful woman. Read reviews and date millionaire singles. https://www.verifiedmillionairedatingsites.com/

1 0

Announcement: pip 20.1b1 beta release
by Pradyun Gedam 30 Apr '20

30 Apr '20

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.

3 5

PyPi not allowing duplicate filenames
by Chris Barker 20 Apr '20

20 Apr '20

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

13 24

ImportError running 'test' on namespace package - other package in namespace not found
by Jason R. Coombs 17 Apr '20

17 Apr '20

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

3 6

Online talk in 90 min: how pip works internally
by Sumana Harihareswara 07 Apr '20

07 Apr '20

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 0

Preview: Upcoming changes to PyPI BigQuery public dataset
by Ernest W. Durbin III 30 Mar '20

30 Mar '20

Hello! I’m looking for anyone how has built something interesting using the PyPI Big Query public dataset that’s documented at packaging.python.org/guides/analyzing-pypi-package-downloads. There are some changes that are coming up that we’d like to preview for users that are actively using the dataset. If that’s you, send a note to bigquery-feedback(a)pypi.org with how you’ve been using the dataset. I’ll get back to you with information on the upcoming changes and will select a few projects to feature in the announcement of the new changes. -Ernest W. Durbin III Director of Infrastructure Python Software Foundation

1 0

Install distutils with pip3
by Samuel Mutel 28 Mar '20

28 Mar '20

Hello, I would like to know if distutils could be installed in python3 environment with pip3 ? Thanks.

2 1

Pipenv - Use system python lib for one package
by Samuel Mutel 28 Mar '20

28 Mar '20

Hello, I have a pipfile like this. I would like to install python-apt library but not from pypi but from the system. Is-it possible? This python library is no longer supported on pypi but is supported in the package distribution. [[source]] name = "pypi" url = "https://pypi.org/simple" verify_ssl = true [dev-packages] [packages] ansible = "==2.8.4" ansible-lint = "*" molecule = "*" docker-py = "*" [requires] python_version = "3"

2 4

Next Pipenv Release
by Dan Ryan 27 Mar '20

27 Mar '20

Hey all -- With Sumana's help, I've been working to get the next pipenv release out by the end of the month. As some of you may already know, I recently changed jobs and am now working for Canonical where I have part of my time allocated to open source work in general (and pipenv in particular). The main pipenv release blockers have been fixes in andnew releases of requirementslib, pythonfinder, pip-shims, and vistir, and merging https://github.com/pypa/pipenv/tree/feature/vendor-updateto address missing dependencies/imports.I've beenworking on these and should wrap up this week.|[0]| You can help in a few ways: 1. Look at the tracking issue for the new release https://github.com/pypa/pipenv/issues/3369and speak up there if you know of a release blocker that isn't in the list. 2. If you see me in #pypa-dev on Freenode IRC, feel free to ask me what I'm working on. Sumana's been keeping me focused this month (and helped me write up the tracking issue, and this email) and it's been helpful, as I am juggling a lot of obligations and can get distracted.|[1]| 3. I could use help replying to new users' questions in pipenv GitHub issues, so I can concentrate on the new release. If you'd like triage permissions on the project please reach out, I'd be happy to give them. 4. Documentation! Pipenv documentation, now at https://pipenv.pypa.io/,needs some serious rework. So if you have any skills in this area,the project would really benefit from a critical review here. 5. Make sure to say 'thanks' to Sumana if you see her on IRC, she is responsible for moving this release forward and is pretty great! I'd appreciate the help. Thanks, -Dan Ryan (techalchemy) |[0]:| You can look at https://github.com/pypa/pipenv/issues/3742#issuecomment-492100711and https://github.com/pypa/pipenv/issues/4058#issuecomment-565550646for more context on why we've been delayed on a new release since November 2018. |[1]|: Iacknowledge that I've been super behind on this release,but I also have moved, had a fire in my new house, changed jobs, etc., and am onlynowsettling into my new role where I finally am paid to spend some time on pipenv.So, after this release is out, I hope to get back to helping new contributors more so we can promote some more co-maintainers, so this doesn't block releases again. -- Dan Ryan @techalchemy | Pipenv Maintainer

2 1

(no subject)
by aaa rrr 26 Mar '20

26 Mar '20

مؤسسته

1 0

PEP 440
by Jose Quevedo 25 Mar '20

25 Mar '20

1 0

comment avoir Matlibplot sur Python 3.8.2 sur MAC OS Mojave ?
by moise amsellem 25 Mar '20

25 Mar '20

1 0

PEP 440
by Rosemary Gutierrez 25 Mar '20

25 Mar '20

1 0

pip resolver work chugging along
by Sumana Harihareswara 24 Mar '20

24 Mar '20

The alpha or beta release of pip with its new dependency resolver should be out in May. I just posted https://pyfound.blogspot.com/2020/03/new-pip-resolver-to-roll-out-this-year… which discusses what is going to change in the pip resolver, when, and how you can help (including some low-effort things you can do right now). I didn't mention this in the blog post because ordinary Python users shouldn't try it, but: As of right now, people who install pip from GitHub master will have the ability to run `pip install --unstable-feature=resolver` and test the new resolver code. And less than half of the test suite fails! Expect errors and missing features, but it’s there! [Celebratory trumpet honk here.] Hope all of you, and all the people you are close to, are healthy and staying that way. -- Sumana Harihareswara pip project manager (contracting with Python Software Foundation) Changeset Consulting https://changeset.nyc

5 11

(no subject)
by 郭罗华 24 Mar '20

24 Mar '20

发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用

1 0

(no subject)
by وائل عبدالمولى 23 Mar '20

23 Mar '20

1 0

Questionable package in PyPi, maybe malicious
by Evagelos 21 Mar '20

21 Mar '20

Hi there, I searched PyPi for "flaskmigrate" and this came up: flaskmigrate - A package to prevent exploit Seems strange to me so I wanted to make you aware, I was advised to report in this mailing list. Regards, Evagelos

2 3

My email address
by Evagelos Theodoridis 21 Mar '20

21 Mar '20

evagelos.theo(a)gmail.com

2 1

Today: livestreamed talk about PyPI malware detection
by Sumana Harihareswara 16 Mar '20

16 Mar '20

Today at 1pm PT/4pm ET: a livestreamed presentation by Cristina Muñoz, who's been working on the PyPI malware detection feature: https://www.meetup.com/pacifichackers/events/267932809/ "Automatic Detection of Malware in PyPI" Alternate link: https://phack.my.webex.com/phack.my/j.php?MTID=mdb827dc0a7f6dfe9784f793686e… She noted: > A general note: this is a presentation geared more towards security folks. A lot of the Python stuff I talk about might feel really redundant/obvious for people who are software engineers and have Python familiarity. Like, there are several slides describing what PyPI is, and the difference between packages, releases and files, for example. -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

1 1

replacement for tests_require?
by Felix Schwarz 09 Mar '20

09 Mar '20

Hi, what is the recommended to solution to declare dependencies which are only required to run tests? In the past there was "tests_require" but as far as I know this is deprecated. I tried to read obvious github issues but maybe I missed something so please bear with me if this has come up way too often. I appreciate pointers. Felix

3 3

Provide a way to bundle and extract license files
by Steve Jorgensen 07 Mar '20

07 Mar '20

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.

4 8

[setuptools] Install entry point only if extras_require are satisfied?
by Jonatan Palsson 06 Mar '20

06 Mar '20

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

2 1

The base docker images for manylinux appear to be private
by Sylvain Corlay 01 Mar '20

01 Mar '20

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,

5 8

Mailing list
by Daniel Scott 26 Feb '20

26 Feb '20

Sent from Yahoo Mail on Android

1 0

parver: parse and manipulate PEP 440 version numbers
by Frazer McLean 21 Feb '20

21 Feb '20

Hi, parver is my package for parsing and manipulating PEP 440 version numbers. I have just released version 0.3. For more information: PyPI: https://pypi.org/project/parver/ Repository: https://github.com/RazerM/parver Documentation: https://parver.readthedocs.io/en/latest/ Thanks, Frazer

2 2

PyCon US 2020 Packaging Summit: Registration and Topic Proposal
by Paul Ganssle 19 Feb '20

19 Feb '20

/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.

1 0

Mailing list
by Daniel Scott 19 Feb '20

19 Feb '20

Sent from Yahoo Mail on Android

1 0

Surviving a Compromise of PyPI - PEP 458 and 480
by Vladimir Diaz 13 Feb '20

13 Feb '20

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.

7 53

Deleted PyPI project
by sabrygad＠buffalo.edu 12 Feb '20

12 Feb '20

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

4 5

travis failures
by Robin Becker 11 Feb '20

11 Feb '20

I have just seen all my manylinux builds fail at https://travis-ci.org/MrBitBucket/reportlab-mirror they all seem to fail in the multibuild install_run phase. I haven't altered anything related to .travis.yml since the previous run on Jan 17th. All the failures seem to relate to a cdn bucket the runs all end with something like this Looking in links: https://5cf40426d9f06eb7461d-6fe47d9331aba7cd62fc36c7196769e4.ssl.cf2.rackc… 1483Collecting pillow 1484 Downloading Pillow-6.2.2-cp27-cp27m-manylinux1_i686.whl (2.0 MB) 1485Installing collected packages: pillow 1486Successfully installed pillow-6.2.2 1487DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support 1488ERROR: You must give at least one requirement to install (maybe you meant "pip install https://5cf40426d9f06eb7461d-6fe47d9331aba7cd62fc36c7196769e4.ssl.cf2.rackc…"?) but I cannot find that in my .yml or the travis config file which I use. Any idea what could be causing this? -- Robin Becker

2 5

Dating
by johncoli900＠gmail.com 10 Feb '20

10 Feb '20

The <a href="https://tinderdatingsites.com/">tinder dating site</a> is used to meet sexy girls whom you can have a healthy relationship. If you are single and wanted to have a relationship then don't worry you can use <a href="https://adultfriendfinderz.co/">adult friend finder</a> to meet hot people.

1 0

Troubles with pip
by George R Goffe 09 Feb '20

09 Feb '20

Hi, I'm very new to this python community. This system is a FedoraCore 32 x86_64 (Rawhide) freshly installed. I was reading about beautifulsoup... and was directed to use pip "pip install beautifulsoup4". I got nothing. strace -xvfp <pid of pip> shows that pip is in (hung?) in the recvfrom(...) system call. Is pip trying to "talk" with a site that's down? Perhaps I'm not doing something correctly? Thanks for your help, George...

2 1

"requirement" corner case
by Gordon Messmer 31 Jan '20

31 Jan '20

I'm working on tools to convert python packaging data to rpm spec files. Most of the conversions are relatively straightforward, but there's an odd corner case with ">" and versions ending in ".*". That combination is parsed as a valid specification, but oddly, it seems to behave the same as ">= version", as demonstrated below. Is this intentional, or is it a byproduct of parsing ">1.0.*" as a LegacySpecifier? Should I convert ">1.0.*" into ">=1.0" and mimic the current behavior, or into something else, like "> 1.0", or ">= 1.1"? >>> pkg_resources._vendor.packaging.requirements.Requirement('cairocffi > 1.0.*,< 1.0.1').specifier._specs frozenset({<LegacySpecifier('>1.0.*')>, <Specifier('<1.0.1')>}) >>> '1.7' in pkg_resources.Requirement.parse('foo>1.7.*') True

2 3

Virtualenv 20.0.0 beta1 is available
by Bernat Gabor 28 Jan '20

28 Jan '20

More information available at https://discuss.python.org/t/virtualenv-20-0-0-beta1-is-available/3077

1 0

pip 20.0 release!
by Pradyun Gedam 21 Jan '20

21 Jan '20

Hello everyone! On behalf of the PyPA, I am pleased to announce that pip 20.0 has been released. This release contains quite a lot of changes (you can see the full list here <https://pip.pypa.io/en/stable/news/>). The highlights for this release are: - Shorter filenames in output, when installing from PyPI. - Automatic fall back to user installs, when main site-packages directory is not writable and user installs are allowed. - Significantly improved wheel building and wheel caching. - Significantly reworked PEP 425 (binary compatibility tag) computation. - Better handling of system packages in virtual environments created with `venv` (PEP 405). - Older pip entry points have been reinstated temporarily, to aid users with stale wrapper scripts. We expect that upgrading to this version of pip, would be painless for most users. We recommend that users test the release before deploying in production, as with any other software release. 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. Cheers, Pradyun

1 0

localization, accessibility, & security progress on PyPI
by Sumana Harihareswara 17 Jan '20

17 Jan '20

I've just posted a final progress report on Discourse about the last month of Open Tech Fund-supported progress on PyPI's localization and accessibility features. Including a screenshot and a bar graph! https://discuss.python.org/t/pypi-localization-accessibility-progress/2284/4 We've finished our OTF-funded accessibility & internationalization work. And sometime this month people will be able to use PyPI in Brazilian Portugese and Japanese! -- Sumana Harihareswara PyPI project manager Changeset Consulting https://changeset.nyc

1 1

Deal with pip setup.py name and rpm packaging
by Marco Favero 15 Jan '20

15 Jan '20

Hello, recently I started to develop a tool in python. I discovered pip and setuptool with setup.py. It's fantastic! I can provide packaging to pypi and to rpm all in a row. I follow these guidelines: - https://packaging.python.org/tutorials/packaging-projects/#generating-distr… - https://docs.python.org/3/distutils/builtdist.html?highlight=rpm - https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ With %{?python_enable_dependency_generator} the RPM provides the dependecies itself. Fantastic! But how to force the developers to use consistent names? :D For instance these python-magic and redis client packages: https://pypi.org/project/python-magic https://pypi.org/project/redis/ use names which conflict with already existent rpm packages names. In particular, "redis" in rpm is the name of the Redis server package! If I make "bdist_rpm" of python Redis client and I "yum install" the package I damage my system deleting the Redis server! The Redis client developer says that he can't change the name because this will break existent installations: https://github.com/andymccurdy/redis-py/pull/385 I think this is not a good situation. Python environment should help to improve an "inconsistent" setup. As a result, I have to make bdist_rpm of the dependencies, then I have to install the source rpm, change the name in SPEC file and rebuild the rpm package. In my package I can't use %{?python_enable_dependency_generator}, because it uses the fault pypi names, I have to provide them myself. :( Thank you for reading this noise Have a fantastic python day Marco

2 2

Packaging Summit 2020: Save the Date!
by Paul Ganssle 15 Jan '20

15 Jan '20

Greetings one and all! Each year millions of eyes around the world eagerly wait at their computer with baited breath to learn the timing of the most fabulous, extravagant, decadent and hyperbolically oversold event of the year: The Python Packaging Summit. While most of the details aren't finalized (and in fact basically no details are finalized), in the interest of giving those who would like to attend a chance at some additional notice on their travel plans, we have established that the date of the summit: *Thursday, 16 April 2020* (the day before the first PyCon talk day). For the past two years we've unofficially held our mini-summit on the first day of PyCon Sprints, but given that this summit is of particular interest to maintainers - many of whom would like to spend the first day of sprints actually sprinting - we have decided to run the summit on the tutorials day parallel to the Education Summit. We have applied for a spot in the Hatchery program, but even if we are not accepted as an official PyCon evenat, we will make arrangements to run the summit off-site on that day. For those unaware of the nature of the summit, you may want to pay attention to the "hyperbolically oversold" portion of my description less than the "decadent" and "extravagant" portions. The purpose of the summit is to get a bunch of people interested in Python Packaging together to discuss and coordinate on important topics in packaging and how we can move them forward. If you are on the fence about joining and want to know more, here are some detailed notes taken at the summit last year: https://docs.google.com/document/d/1Wz2-ECkicJgAmQDxMFivWmU2ZunKvPZ2UfQ59zD… As I mentioned earlier, we have finalized essentially *no* details of this summit other than the date. I do not know how many people will be able to attend or by what mechanism we will prioritize attendance at the summit if there is limited space. In the coming months please keep an eye out for: * Registration details (if such a thing is deemed necessary) * A call for topic suggestions * Voting on how to prioritize topic suggestions Looking forward to seeing you all there! Paul

4 3

With setuptools, “optional” C extension module error is fatal
by Dan Stromberg 15 Jan '20

15 Jan '20

Hi folks. (There's a copy of this message on stack overlfow at https://stackoverflow.com/questions/59522262/with-setuptools-optional-c-ext… ) I'm putting a little time into getting my treap module (like a dict, but always sorted by key) working with distutils. I want it to be able to compile and install the Cython version from an included .c file, or to fall back on a pure python version if that fails. I'm currently using: setup( name='treap', py_modules=[ 'treap', 'py_treap', 'nest', ], # ext_modules=cythonize("pyx_treap.pyx"), ext_modules=[Extension('pyx_treap', ['pyx_treap.c'], optional=True)], # setup_requires=[ # 'Cython' # ], version=version, description='Python implementation of treaps, ) ...plus a few more options to setup that don't seem relevant. If I run python3.6 setup.py build, I get: running build running build_py creating build creating build/lib.linux-x86_64-3.6 copying treap.py -> build/lib.linux-x86_64-3.6 copying py_treap.py -> build/lib.linux-x86_64-3.6 copying nest.py -> build/lib.linux-x86_64-3.6 running build_ext building 'pyx_treap' extension creating build/temp.linux-x86_64-3.6 x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.6m -c pyx_treap.c -o build/temp.linux-x86_64-3.6/pyx_treap.o pyx_treap.c:4:10: fatal error: Python.h: No such file or directory #include "Python.h" ^~~~~~~~~~ compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 So it seems like despite using Extension('pyx_treap', ['pyx_treap.c'], optional=True), the cython version is not optional. Am I missing something? Why doesn't it just continue with the pure python modules? I realize I could install python3.6-dev or similar to eliminate the error, but I don't want to assume the user knows that. Thanks!

1 1

setup.py test deprecation timeline
by bmw＠eff.org 15 Jan '20

15 Jan '20

Is there an ETA for when setuptools is going to break the test subcommand? It would be useful for me to know how long I have to stop using tests_require and to help OS package maintainers migrate to a new way of running tests. Thanks for any info! Brad Warren

2 1