Distutils-SIG October 2013

distutils-sig@python.org

48 participants
48 discussions

by Paul Moore

With all of the current interest in bundling pip with the Python distribution, I had a sudden thought. Vinay has developed a package called pyzzer (https://pypi.python.org/pypi/pyzzer) that bundles up Python modules into runnable single-file executables. Using a command pyzzer -m pip:main -l t64 -o pipsa.exe -s "#!python" -r <path-to-pip>\pip you can build a single-file executable version of pip that can install wheels (it can't install sdists until setuptools is installed, because installing sdists depends on having setuptools at install time). The -s "#!python" is not needed on Unix as the default is "#!/usr/bin/env python". Also the -l t64 is a Windows requirement to get an exe - you can produce a cross-platform pyz archive without it (see the pyzzer docs for details). This requires the latest development version of pip (which contains a fix for running pip from an uninstalled zipfile) and the following patch to pip\__init__.py: Change: from pip import cmdoptions to: import pip.cmdoptions cmdoptions = pip.cmdoptions This fixes a recursive-import issue - I'll update pip "real soon now" (TM) for this. This is just an experiment at the moment - I've done minimal testing but it seems to work as I'd expect. It may be worth thinking about, though - either as an alternative to bundling (a bit late, I know) or as a way of providing pip for earlier versions of Python. Hope this is of interest. Paul

7 years, 4 months

post install hook

by Thomas Güttler

Hi, I can live without a post-install hook. But I think the documentation of setuptools should contain information about this. https://bitbucket.org/pypa/setuptools/issue/92/docs-post-install-hook

7 years, 4 months

Warehouse - Simple API

by Donald Stufft

I've recently deployed the current Warehouse code. So far the simple API has been implemented and it would be great if people could point their installers to it and report back to me if they run into any problems. The current PyPI simple api is not documented at all so I've had to reverse engineer it going from what I know, pip, etc. Ideally if i've missed anything it will be found out with testing from y'all. You can try the warehouse code by setting your installers to use the url https://preview-pypi.python.org/simple/ . This url *will* be removed eventually so do not depend on it. It is backed by the same database as PyPI so all of the same packages should exist and be installable. It is not powered by the CDN at the moment. I welcome any reports of problems either by response to this thread, privately to me, or on the issue tracker at Github [1] [1] https://github.com/dstufft/warehouse/issues ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

7 years, 4 months

URL Structure of Packages URLs

by Donald Stufft

I was wondering if anyone was aware of anything that relies on the current structure of package urls, namely: /packages/source|any|etc/D/Django-1.0.tar.gz? I would like to change this but before I work up a concrete plan for people to comment on and discuss I'm trying to figure out what, if anything, depends on that current structure. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

7 years, 4 months

distil 0.1.2 released

by Vinay Sajip

I've released version 0.1.2 of distil, downloadable from [1]. It's based on distlib 0.1.3, which brings support for PEP 426. The other changes are as follows: * Fixed a bug in pre-release handling which occurred when there were *only* pre-releases available. * Added support to convert "bdist_wininst" installers to wheels. This is done by using "distil package", specifying only the wheel format and giving the path to the installer in place of the source directory. * Added --wheel-version option to package command to allow specifying a wheel version when building wheels. * Fixed bugs in uninstallation code which occurred only for some installations. * Fixed a bug in package data installation where data in packages not explicitly named in package-data was missed. * Updated "distil link" to show existing links when invoked with no arguments. * When building wheels, native executable launchers are not included, and scripts are not generated from exports. * Added support for PEP 426 installation hooks. * Added --target argument to "distil install" to allow partial installation to arbitrary directories. * Added --prereleases argument to "distil install", "distil test", and "distil download" to support inclusion of pre-releases when locating distributions and performing dependency resolution. * Numerous documentation updates. Your feedback will be gratefully received! Regards, Vinay Sajip [1] https://bitbucket.org/vinay.sajip/docs-distil/downloads/distil.py

7 years, 4 months

Deprecate and Block requires/provides

by Donald Stufft

As many are aware distutils has the "requires" field and such. These fields are designed to list something you *import* not something you install from PyPI. I believe these fields to be generally useless, supported by the fact distutils2 deprecated them, and outright user hostile. Users do not tend to realize that these aren't PyPI distributions and attempt to use them for that case. This generally "works" in that it will show up on PyPI but it will fail as soon as a distribution contains a character like -. So what I would like to do is "remove" these fields. This would consist of modifying PyPI to return an error code if they are included and hiding the existing data in the UX. It might at a future time also consist of removing the data from the DB all together. What do people think? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

7 years, 4 months

PEP 453 - virtualenv change to Scripts/bin directory

by Paul Moore

As part of PEP 453, there is a proposal to change the layout of python environments on Windows by renaming the "Scripts" directory to "bin" (to match other platforms). The PEP is targeted at Python 3.4 (core and venv module) but for consistency virtualenv should also change to match (only for virtualenvs based on Python 3.4+, obviously). This change could potentially affect tools that build on virtualenv (tox, virtualenv-wrapper, for example). Coping with the change should be relatively easy - where code currently uses "Scripts" on Windows, they can simply check to see which of "Scripts" and "bin" exists and use that. Could anyone who has code like this please check if this change will cause them problems and let us know? Thanks, Paul

7 years, 4 months

zc.buildout bootstrap.py v1 died / python-distribute.org down

by Adam GROSZER

Hi, python-distribute.org seems to be down, that breaks zc.buildout v1 bootstrap.py when used with "-d" to use distribute. -- Best regards, Adam GROSZER -- Quote of the day: "Some days you're the dog, and some days you're the hydrant."

7 years, 4 months

develop install: how to update entry point file

by Thomas Güttler

Hi, what needs to be done, to get an update of the entry_point file, if you have installed a package as "develop". Example: pip install -e ...#egg=mylib git update # new code contains new entry point ... entrypoint not available. Thomas

7 years, 4 months

dependency_links format changed?

by Thatcher Peskens

Hi all, I've been looking for information on this topic, but cannot really find anything about it.. It looks like setuptools has changed something that breaks a bunch of my installs (last deployed months ago) that were working before. I have some dependencies on a python package A* which is not available in PyPi, which itself has dependencies not available on PyPi. A has a setup.py containing: install_requires=[ 'django-inline-edit', ] and dependency_links = [ 'http://github.com/gabrielgrant/django-inline-edit/tarball/master#egg=django…', ] Now... This doesn't work anymore, where it used to work before. I have found that if I specify the install_requires with an explicit version e.g. django-inline-edit==dev AND the dependency_link with #egg=django-inline-edit-dev it does work. My previous experience shows that it was working without the explicit version before, and what I find on the internet also seem to suggest it should work. Has this been changed on purpose, or should it be reported as a bug? Thanks in advance, Thatcher *A -> https://github.com/gabrielgrant/django-easy-pages

7 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG October 2013