Re: [Python-Dev] [Python-checkins] Daily reference leaks (1704deb7e6d7): sum=2
On Sun, 16 Sep 2012 06:54:21 +0200 Ross Lagerwall wrote: > On 09/16/2012 06:04 AM, solip...@pitrou.net wrote: > > results for 1704deb7e6d7 on branch "default" > > > > > > test_dbm leaked [0, 2, 0] references, sum=2 > > > > I've noticed that test_dbm fairly often leaks here although I've never > reproduced it. Does anyone know with which dbm lib this is (gdbm, ndbm, > gdbm_compat, bdb)? It is dbm.dumb. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Fri, Sep 14, 2012 at 8:12 AM, Vinay Sajip wrote: > I have set up a BitBucket repo called distlib, at > > https://bitbucket.org/vinay.sajip/distlib/ > > ... > > The code was taken at around the time packaging was removed, and may not have > more recent changes. Would it be possible or make sense for this effort to start by forking the previous Lib/packaging directory of the cpython mirror on bitbucket (or perhaps do this in a fork of the entire cpython mirror given that portions of this are meant to be cherry-pick merged back to cpython)? That way the continuity with the previous state of packaging would be clear as well as making later merging easier. Also, will the previous Doc/packaging docs live in this new repo? --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Sep 16, 2012, at 6:37 AM, Chris Jerdonek wrote: > On Fri, Sep 14, 2012 at 8:12 AM, Vinay Sajip wrote: >> I have set up a BitBucket repo called distlib, at >> >> https://bitbucket.org/vinay.sajip/distlib/ >> >> ... >> >> The code was taken at around the time packaging was removed, and may not have >> more recent changes. > > Would it be possible or make sense for this effort to start by forking > the previous Lib/packaging directory of the cpython mirror on > bitbucket (or perhaps do this in a fork of the entire cpython mirror > given that portions of this are meant to be cherry-pick merged back to > cpython)? That way the continuity with the previous state of > packaging would be clear as well as making later merging easier. > > Also, will the previous Doc/packaging docs live in this new repo? > > --Chris > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dholth%40gmail.com You would also wind up with the entire cpython history in every checkout. Mercurial allows merging unrelated repositories. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On 14 September 2012 16:12, Vinay Sajip wrote: > I have set up a BitBucket repo called distlib, at > > https://bitbucket.org/vinay.sajip/distlib/ > > This has the following bits of distutils2 / packaging, updated to run on 2.x > and > 3.x with a single codebase, and including tests (though not docs, yet): > > version.py - version specifiers as per PEP 386 > metadata.py - metadata as per PEPs 345, 314 and 241 > markers.py - environment markers as per PEP 345 > database.py - installed distributions as per PEP 376 > depgraph.py - distribution dependency graph logic > glob.py - globbing functionality A nice addition would be an API for managing the RECORD file. I would imagine functions to read/write the file (hiding the details of how to open the CSV file correctly in a cross-platform manner), functions to produce a list of the files installed for a distribution, and functions to validate (and maybe write) the hashes. If this would be useful, I'd be willing to write the code, although my API design skills aren't the best, so some advice on how the API should look would be nice :-) Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
> I agree with Lennart's and Antoine's advice of just move forward with what > we have. If some PEPs need fixing then let's fix them, but we don't need to > rock the horse even more by going overboard. Getting the sane, core bits > into the stdlib as packaging is meant to is plenty to take on. If people > want to reinvent stuff they can do it elsewhere. I personally don't care if > it is done inside or outside the stdlib initially or if it stays in > packaging or goes directly into distutils, but forward movement with what we > have is the most important thing. +100 I was excited about packaging in 2010, it is time to document and implement the specs we have. The sooner we do, the less confusing it will be for a newcomer who just wants to release a simple printer of nested lists to pypi. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Mon, Sep 17, 2012 at 5:05 AM, Daniel Holth wrote: >> I agree with Lennart's and Antoine's advice of just move forward with what >> we have. If some PEPs need fixing then let's fix them, but we don't need to >> rock the horse even more by going overboard. Getting the sane, core bits >> into the stdlib as packaging is meant to is plenty to take on. If people >> want to reinvent stuff they can do it elsewhere. I personally don't care if >> it is done inside or outside the stdlib initially or if it stays in >> packaging or goes directly into distutils, but forward movement with what we >> have is the most important thing. > > +100 > > I was excited about packaging in 2010, it is time to document and > implement the specs we have. The sooner we do, the less confusing it > will be for a newcomer who just wants to release a simple printer of > nested lists to pypi. I've been chatting to Chris McDonough a bit as well, and one potentially useful thing would be to clearly document the setuptools/distribute metadata precisely as it is generated today. Currently these formats are entirely implicit in the implementation of the code that reads and writes them, as far as I can tell anyway. The distribute docs seem to do a decent job of explaining setup.py and the various setuptools specific arguments, but *not* what the file formats will look like inside the metadata directory when installed. The main advantages of this would be to make it clear: 1. What can setuptools metadata describe, that v1.2 of the official metadata standard cannot? 2. Does v1.3 allow everything that setuptools can currently describe (either directly, or as an extension)? 3. Does v1.3 allow some things to be expressed more clearly than they can be with setuptools? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
Paul Moore gmail.com> writes: > A nice addition would be an API for managing the RECORD file. I would > imagine functions to read/write the file (hiding the details of how to > open the CSV file correctly in a cross-platform manner), functions to > produce a list of the files installed for a distribution, and > functions to validate (and maybe write) the hashes. > Producing the list of files installed for a distribution might be tool-specific (e.g. a tool might have additional tool-specific files over and above what any PEPs mandate). There's a method in database.py - Distribution.list_installed_files() - which reads and returns the RECORD entries as (path, hash, size) tuples. I think all that's needed (at the same level of abstraction) is a method write_installed_files(iterable_of_absolute_file_paths) which writes the file. This code is already in the distutils2.install_distinfo.install_distinfo.run() method. I'll pull it out into such a method. Anyone else, do chip in if you think this is insufficient or sub-optimal. Perhaps these discussions (on the detail) should continue on distutils-sig. I'll post there when I've made the changes. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On 16 September 2012 23:26, Vinay Sajip wrote: > I think all that's needed (at the same level of abstraction) is a method > write_installed_files(iterable_of_absolute_file_paths) which writes the file. > This code is already in the distutils2.install_distinfo.install_distinfo.run() > method. I'll pull it out into such a method. Possibly also useful (if only to standardise the approach) would be a method to check hashes against installed files. Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
