Mailman 3 - Distutils-SIG

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

Jan. 17, 2019

Hello, I am currently developing an application called "Outbreak" and would like to release a package to Pypi. However, there already exists a package with that name <https://pypi.org/project/outbreak/>. It has no description, has no functionality, and hasn't been updated in four months. According to PEP 541, such a project is considered name squatting and is thus to be considered invalid. May I please request that the project be removed from the Package Index? If you would like, I can contact the author myself. Thank you, Elliot Paton-Simpson

2 1

license python api
by Martin Walchshofer Jan. 17, 2019

Jan. 17, 2019

Hello, i'm software engineer at g.tec. We're building brain computer interfaces. For one of our devices we've built a python .pyd library, that we want to distribute and sell with our software. The user would buy a license key in our webshop, and afterwards he'd be able to unlock and use the api in python. With our installer we'd like to copy the library to a folder on the users machine. By adding this path to the pythonpath, the user should be able to use the library. We don't want to distribute python itself, just the ibrary that we've compiled using python 3.3. I'm having some questions according the python licensing, because it's not completely clear for me: * Are we allowed to provide the compiled .pyd library without the source code for that library? * Do we need to distribute the psf license agreement or any reference to python within our license agreement if we distribute the library? Best, Martin Martin Walchshofer, MSc | Software Engineer g.tec medical engineering GmbH Sierningstrasse 14 | 4521 Schiedlberg | Austria office: <tel:0043725122240> +43 7251 22240 email: <mailto:walchshofer@gtec.at%20> walchshofer(a)gtec.at w: <http://www.gtec.at> www.gtec.at b: <http://blog.gtec.at/> blog.gtec.at f: <https://www.facebook.com/gtecmedical> g.tec medical engineering t: <https://twitter.com/gtec_BCI> @gtec_BCI y: <https://www.youtube.com/channel/UCVR80bpCIQyWgyGa20OLmvw> gtec medical engineering l: <https://www.linkedin.com/company/1627233/> g.tec medical engineering GmbH

1 0

PEP 513
by Md Robul Jan. 14, 2019

Jan. 14, 2019

1 0

alll
by Md Robul Jan. 14, 2019

Jan. 14, 2019

Ddbzzb

1 0

"Packaging and Python 2" on discuss.python.org
by Pradyun Gedam Jan. 11, 2019

Jan. 11, 2019

Hi all! I've opened a topic on discuss.python.org for discussing how to handle the Python 2.7 EOL in the various packaging tools, with the intent of figuring out how we plan to handle this transition. PyPA project maintainers: if you have already documented/announced your plans, it would be great if you could link/mention it in that thread. https://discuss.python.org/t/packaging-and-python-2/662 Best, Pradyun

1 0

Announcing dotlock - another package management tool
by Alex Becker Dec. 31, 2018

Dec. 31, 2018

Dotlock <https://pypi.org/project/dotlock/> is a package management tool similar to pipenv, but with a different philosophy: instead of acting as a wrapper around pip, dotlock handles package resolution natively. This should allow for more flexibility, better performance, and a smaller surface area for bugs, but at the cost of the wide platform and package support the pip developers have put so much work into. Dotlock is still very much beta software, and currently the only users are myself and my company. It works well for our use case (deploying web applications to linux servers), but has some gaps in support I know about (including packages that use setup_requires or pyproject.toml), and probably many I do not. Thanks to everyone on this list who I discussed dotlock and general package issues with at PyCon, and to anyone who tries it out! Sincerely, Alex Becker

1 0

upcoming work to facilitate PyPA communications/roadmaps
by Sumana Harihareswara Dec. 24, 2018

Dec. 24, 2018

It's been eight months since the release of Warehouse[0] and the sunsetting of legacy PyPI[1]. Following up from our meeting at PyCon in May[2], Changeset Consulting is back on board for another round of project management to facilitate next steps! For the next 3-6 months this work will be spearheaded by myself (Sumana) assisted by Jenny Ryan (https://jennyryan.net ). The goal over these upcoming months is to create, steward and facilitate internal and public-facing communications to aid the folks within PyPA. What this means is that we'll be focused on the following: * Facilitating regular meetings of and for maintainers and contributors; * Stewarding communications with various PyPA stakeholders, including funders and users; * Organizing, labelling, prioritizing, and responding to GitHub issues; * Coordinating public communications, such as announcements, sprints, and calls for participation; * Maintaining and improving documentation, meeting notes and development roadmaps for PyPA projects. Feedback from and participation by the Python packaging developer community is obviously part and parcel of this project, so you may see some new "here's what I think is up with this issue, is that right?" questions on old unresolved discussions. And we'll be asking questions on this & other lists and on GitHub and in IRC to collect ideas, concerns, and other productive input regarding the tools roadmaps. You'll be seeing more details in mid-January to properly kick off this next chapter of levelling up PyPI and the PyPA -- just wanted to give y'all a heads-up. But of course, if you were already planning on using the next few weeks to do issue triage and roadmap-writing and PyCon planning, please don't wait for us -- that'll make this work all the easier. Thanks, Sumana Harihareswara [0] https://blog.python.org/2018/04/new-pypi-launched-legacy-pypi-shutting.html [1] https://mail.python.org/archives/list/distutils-sig@python.org/thread/YREMU… [2] https://mail.python.org/archives/list/distutils-sig@python.org/thread/CCOV6… -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

2 1

older pypi packages
by Robin Becker Dec. 18, 2018

Dec. 18, 2018

I recently had to rebuild a server and find that pip 18.1 is apparently unable to install at least some older packages eg > $ bin/pip install fcrypt > Collecting fcrypt > Could not find a version that satisfies the requirement fcrypt (from versions: ) > No matching distribution found for fcrypt the version I needed is in fact the last released 1.3.1 (in 2004) and it was installed by an earlier pip. I tried being more explicit > $ bin/pip install fcrypt==1.3.1 > Collecting fcrypt==1.3.1 > Could not find a version that satisfies the requirement fcrypt==1.3.1 (from versions: ) > No matching distribution found for fcrypt==1.3.1 I assume that latest pip needs information from the package / pypi data that is not available. Luckily installing from a pypi download works. Is there any legacy mode in pip? It seems wrong to cause these older packages to become unusable. -- Robin Becker

4 5

Pypi packages stats on BigQuery
by Laurent Gautier Nov. 24, 2018

Nov. 24, 2018

Hi, Making download stats available through BigQuery seems like a good idea, but as it is currently this seems a bit expensive on a user's end. For example, I just looked at stats for a package of mine and 840GB are reported to be processed (therefore billed) in one query. Is table clustering used when building these tables ? If not, could we have it at least on projects name ? (See the following about table clustering: https://medium.com/google-cloud/bigquery-optimized-cluster-your-tables-65e2… ). Best, Laurent

2 2

Intent to add a "Packaging" category to discuss.python.org
by Donald Stufft Nov. 4, 2018

Nov. 4, 2018

Just an FYI, I’m going to ask the discuss.python.org <http://discuss.python.org/> admins to add a Packaging category to that discourse instance for the discussion of packaging in Python, basically as a sister discussion location to distutils-sig. I plan to primarily participate and centralize my own personal discussions there, although others are free to continue to discuss wherever they would like (although I think it would be great if folks would all jump over there as well!). I’m not going to request any sub categories at this time, both because I don’t think our traffic is high enough to warrant it, and also because I think that tagging will be a more useful mechanism for us since we can tag things with relevant projects or whatever (or not tag things at all) and topics can have multiple tags.

3 6