Mailman 3 July 2013 - Distutils-SIG

Fw: Q about best practices now (or near future)
by Vinay Sajip July 18, 2013

July 18, 2013

Sorry, accidentally left distutils-sig off when replying. ----- Forwarded Message ----- > From: Vinay Sajip <vinay_sajip(a)yahoo.co.uk> > To: Nick Coghlan <ncoghlan(a)gmail.com> > Cc: > Sent: Thursday, 18 July 2013, 8:41 > Subject: Re: [Distutils] Q about best practices now (or near future) > >> From: Nick Coghlan <ncoghlan(a)gmail.com> > > > >> Then (help) write the missing PEP! PEP's don't appear out of > nowhere, > > I think I have been helping as and when I can by participating in the various > discussions, but the PEP has to be written by a champion. I clearly can't be > a champion for this, else why would I be working on distlib? That's what I > currently see as the way forward, obviously, but it's premature to look at a > PEP for it because it hasn't had enough exposure or peer review. > > I have no particular axe to grind against pip - I did a lot of the core work for > the single code-base port, speeded up the test suite a fair bit, and have > contributed other bits and bobs. However, it is the past and present of > packaging, as I see it, and not a worthy long-term future - it has too much > technical debt. As the de facto installer for Python, pip needs no additional > new endorsement, in my view. If I had to choose, I would say I find none of the > choices especially appetising, but I would choose an explicit bootstrap over the > others. Note that installing Distribute/pip was explicitly removed from the > pyvenv script before 3.3 beta, because of python-dev concerns about promoting > specific third-party solutions in the stdlib (even though they were the defacto > tools for Python 3.x, and endorsed as such by python-dev).. > > Nothing has essentially changed from the 3.3 beta time frame. People still use > pip, just as they always did. The recommendation from python-dev is as it always > was (use pip), with a slight alteration on the Distribute front due to the merge > with setuptools. Neither pip nor setuptools are *significantly* better than they > were in functional terms, and if they weren't the right solution when > distutils2/packaging was mooted, I don't see why that should have changed > now. > >> these approaches (up to and including misstating that dislike as "not > >> going to happen"), that just means the arguments in favour would need >> to be a bit more persuasive to convince me I am wrong. > > That's not how "not going to happen" comes across. You're > saying it's a misstatement in this off-list mail, but as you are the > packaging BDFL, some people on-list would just give up when they saw that. > >> The problem statement also needs to be updated to cover the use case >> of an instructor running a class and wanting to offer a local PyPI >> server (or other cache) without a reliable network connection to the >> outside world, since *that* is the main argument against the >> bootstrapping based solutions. > > > How widespread is that scenario, really, in this day and age? I consider this a > straw man. If that really is a case to cover, you can make a getpip script cover > this contingency with a command-line argument, the pip and setuptools packages > can be stored on the local PyPI cache, and so on. It's no more onerous than > explaining to the students, for example, the pip command line parameters you > would need to specify to access a local PyPI cache. From my experience, over the > course of a class students will run many commands, some of which they don't > fully understand, under the guidance of the instructor. > > I have to say, I'm not comfortable with the *level* of some of the > arguments/points put forward - for example, that "we already had a get-pip > command, using curl URL | python". They come across as unconsidered, more > like rationalisations for a course already set, and it's hard to engage in a > debate which doesn't feel right. > > Regards, > > Vinay Sajip >

2 1

distribute 0.7.3 causing installation error? follow up
by Liam Kirsher July 17, 2013

July 17, 2013

Hi, Also, just noticed that 0.7.3 is available as .zip, but not as .tar.gz like the others are. Liam -- Liam Kirsher PGP: http://liam.numenet.com/pgp/

1 0

PEP 426 updated based on last round of discussion
by Nick Coghlan July 17, 2013

July 17, 2013

I actually pushed this to python.org on the weekend but forgot to announce it on the list. The latest version of PEP 426 is up at http://www.python.org/dev/peps/pep-0426/ It was a net deletion of content despite going into more depth in a few areas, so I'm counting that as a win for clarity :) Change details are at http://hg.python.org/peps/rev/067d3c3c1351 Significant changes: * serialisation prefix changed to "pydist". This metadata is the metadata that exists at the sdist level. Wheels and installation may add other metadata files, and PyPI will publish additional metadata extracted from the archive contents, so I decided "pymeta" didn't feel write (the name of the schema file changed as well, but I did that in a separate commit so the diff stayed readable) * all the *_may_require fields are gone (as previously discussed) * rather than "install specifiers" I went with "requirement specifiers" (install turned out not to read very well) * accordingly, the subfields of dependency specifiers are "requires", "extra" and "environment" * the abbreviated form (which has "requires" as a list) was easy enough to specify, so that's what I used. The unpacked form (where multiple entries in the same dependency list have the same extra/environment combination) is explicitly disallowed in order to encourage consistent formatting. * clarified that internal whitespace is permitted in requirement specifiers (there may be a simpler way to specify this, such as "all whitespace in requirement specifiers is ignored") * I made the change to explicitly distrust "Provides" data retrieved from a public index server, and noted that projects defining a virtual dependency should claim that name to define the default provider. * noted that Debian packagers may want to map extras to Recommended or Suggested packages * noted some possible use cases for metadata extensions * fixed and clarified various things in the reference copy of the JSON schema (it could still do with an audit against the current PEP text, though) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 11

Re: [Distutils] buildout doesn't work as expected, please help me
by Benedek Zoltan July 17, 2013

July 17, 2013

Hi, I suspect the problem is with the changing infrastructure of setuptools-distribute. I'm happy to hear of this merge, thank you for all of you, who contributed to these tools. https://python-packaging-user-guide.readthedocs.org/en/latest/current.html I tried to clean everyting buildout made: rm -rf bin/ eggs/ parts/ rm bootstrap.py.installed.cfg wget http://downloads.buildout.org/1/bootstrap.py python bootstrap.py and after several tries finally worked. Could be helpful too: http://reinout.vanrees.org/weblog/2013/07/08/new-setuptools-buildout.html http://www.coresoftwaregroup.com/blog/distribute-setuptools-and-a-failing-b… Thanks Zoli

2 1

devpi-0.9.3: new list/remove commands, bugfixes
by holger krekel July 17, 2013

July 17, 2013

I just released new versions of the devpi system, which provides a self-updating pypi caching and index server and a ``devpi`` command line tool to help with common upload/test/release activities. devpi-0.9.3 comes with some bug fixes and two new sub commands to view and remove release files from a private index. For general docs see: http://doc.devpi.net and for the changelog see below. Special thanks to Anthon van der Neut for his contributions, in particular the "argcomplete" support allowing for <tab> completion on options and subcommands. best, holger 0.9.3 ---------------------------- server: - fixed issue9: caching of packages where upstream provides no last-modified header now works. - fixed issue8: only http/https archives are allowed and other schemes (such as ftp) are silently skipped - added support for REST DELETE methods of projects and versions on an index - added "argcomplete" support for tab completion on options (thanks to Anthon van der Neut) client: - new "devpi list" command to show projects of the in-use index or all release files of a project with "devpi list PROJECTNAME". - new "devpi remove" command to remove releases from the current index, including any contained release files - added "argcomplete" support for tab completion on options (thanks to Anthon van der Neut)

1 1

Expectations on how pip needs to change for Python 3.4
by Paul Moore July 17, 2013

July 17, 2013

This issue has been skirted round for some time now, and I think it needs explicit discussion, as I am not at all sure everyone has the same expectations. We're talking about Python 3.4 installations having pip as the default package manager - whether by bundling, having a bootstrap process or whatever. Regardless of the means, pip will be *the* installer for Python 3.4+. And yet, I don't think pip 1.4 currently does what people want "the Python 3.4 pip" to do in some ways - and we need to make sure that any work on the pip side is understood, agreed to, and planned to match the Python 3.4 timescales. So, here's my initial list of things that I think people might be expecting to happen. This is just my impressions, and I don't necessarily have a view on the individual items. And if anyone else can think of other things to add to the list, please do so! 1. Install to user-packages by default. 2. Not depend on setuptools (??? - Nick's "inversion" idea) 3. Possibly change the wrapper command name from pip to pip3 on Unix. 4. Ensure that pip upgrading itself in-place is sufficiently robust and reliable that users don't get "stuck" on the Python-supplied version. I'm sure I've seen people say other things that have made me think "are you expecting the pip maintainers to make that change?" in the various threads, so I doubt this list is definitive. Comments anyone? Is this discussion premature? The pip maintainers team is not huge, so we'll need time (or assistance!) to plan in and make changes like this, if they are needed... At a minimum, can we get the key items logged on the pip issue tracker with a milestone of Python 3.4? Paul

12 56

distribute o.7.3 causing installation error?
by Liam Kirsher July 17, 2013

July 17, 2013

2 1

distribute 0.7.3 causing installation error? follow up
by Liam Kirsher July 16, 2013

July 16, 2013

Hi, Also, just noticed that 0.7.3 is available as .zip, but not as .tar.gz like the others are. Liam -- Liam Kirsher PGP: http://liam.numenet.com/pgp/

1 0

buildout doesn't work as expected, please help me
by Benedek Zoltan July 16, 2013

July 16, 2013

Hi, I'm relatively new to buildout, but untill now I could manage to install python packages, supervisord, config files and run system commands by buildout, using the recipes: z3c.recipe.scripts collective.recipe.supervisor collective.recipe.template plone.recipe.command Sometimes I had a timeout error like: "Installing pypackages. While: Installing pypackages. Getting distribution for 'python-dateutil'. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): ..." and "timeout: timed out" but generally worked. Recently I get nearly always this error or an other one: " Getting distribution for 'zc.buildout>=1.7.1,<2dev'. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): ..." and "timeout: timed out" I tried: 1. to run even with: bin/buildout -t 30 2. to put this in buildout.cfg find-links = http://a.pypi.python.org/simple/ http://b.pypi.python.org/simple/ http://c.pypi.python.org/simple/ http://d.pypi.python.org/simple/ http://e.pypi.python.org/simple/ http://f.pypi.python.org/simple/ http://g.pypi.python.org/simple/ 3. I changed z3c.recipe.scripts to zc.recipe.egg Unfortunately the problem is not solved. Any help will be greatly appreciated. Thank you Zoli

1 0

pip and virtualenv release candidates
by Marcus Smith July 15, 2013

July 15, 2013

pip-1.4rc2 and virtualenv-1.10rc3 are available for testing from github. A few highlights: - pip added support for installing and building wheel archives. ( http://www.pip-installer.org/en/latest/cookbook.html#building-and-installin… ) - virtualenv is now using the new merged setuptools, and no longer supports distribute. - pip now only installs stable versions by default, and offers a new --pre option to also find pre-releases. - Dropped support for Python 2.5. Changelogs: pip: http://www.pip-installer.org/en/release-1.4/news.html virtualenv: http://www.virtualenv.org/en/release-1.10/news.html Download Links: pip: gz: https://github.com/pypa/pip/archive/1.4rc2.tar.gz md5=0426430fc8a261c83bcd083fb03fb7d6 zip: https://github.com/pypa/pip/archive/1.4rc2.zip md5=c86dc0d94ed787eadba6dceb06f1676f virtualenv: gz: https://github.com/pypa/virtualenv/archive/1.10rc3.tar.gz md5=b24cdf59b561acf26ae3f639098d5a34 zip: https://github.com/pypa/virtualenv/archive/1.10rc3.zip md5=a6ee1a1570a751aa50f95833d9898649 Installation: The easiest way to try them both and *not* affect your current system, is like so: e.g. on Linux: $ curl -L -O https://github.com/pypa/virtualenv/archive/1.10rc3.tar.gz $ echo "b24cdf59b561acf26ae3f639098d5a34 1.10rc3.tar.gz" | md5sum -c 1.10rc3.tar.gz: OK $ tar zxf 1.10rc3.tar.gz $ python virtualenv-1.10rc3/virtualenv.py myVE $ myVE/bin/pip --version pip 1.4rc2 *Note*: If instead, you choose to upgrade an existing pip (and setuptools), know this: 1) pip's wheel support requires setuptools>=0.8b2 (this will become final before pip is released final) 2) setuptools-0.8bx is not on pypi and can be found here: https://bitbucket.org/pypa/setuptools/downloads 3) Older pip's can not currently upgrade distribute to setuptools (until distribute-0.7.3 is released on ~July-7th) (for more upgrade details: http://www.pip-installer.org/en/latest/installing.html#requirements) Offering Feedback: You can respond to this email, or log issues in our tracker: https://github.com/pypa/pip/issues?state=open

2 6