Re: multiple modules in one source
On 3 February 2015 at 16:15, Robert Collins
wrote:
> Whats the actual upstream, and what do you want users to have
> available in terms of Debian packages?
>
Ok, I think I have worked out it now, however will just summarize more
details here.
Lets say I maintain a project called "karaage"[1].
To try and be flexible, lets say I split up some parts of Karaage into
plugins[2]; I split them up into separate git source, hence separate
distributable and packages. This is because some plugins are not needed by
some installations, and require large dependencies (e.g. matplotlib), of
which some don't have Python 3 packages in wheezy (and not easy to fix this
due to old Python 3 in wheezy).
ie. karaage contains the karaage python package, karaage-applications
contains the kgapplications python package, etc.
This worked well, it was possible to install only the plugins you needed,
and you can manually change the configuration to enable or disable them.
Then, one of the hypothetical users of this hypothetical project
subcontracted a hypothetical development company to do hypothetical
development of the project in a direction that suited their hypothetical
business needs. This is fine, it is open source software, I am perfectly
happy with this. At the time they promised that they were going to work
with me to make sure I was happy with the changes, and all users would
eventually benefit. They created their own fork to do this development[3].
However this development team made the decision, without consulting me, to
combine all the plugins into one git repository. They made the argument
that is was easier to test having all the packages exist in the CWD. eg.
karaage now contains ./karaage, ./karaage-applications, etc.
However, unfortunately, they seem to have neglected to deal some issues,
like not having to install the dependencies for these plugins (especially
for Debian package), or being able to disable a plugin (since they also
coded autodetection of installed plugins[4]), or being able to
automatically test the base package with and without the plugins installed.
Since then, the user that was funding the development seems to have
misjudged availability of funds, and funding for this development has dried
up. As a result, it appears, I have lost contact with these developers too.
So as the "official maintainer", I was trying to decide if it is worth
persisting with this new combined source code.
I am inclined to keep the structure as unchanged from how I have it -
separate git repositories for the different plugins - I think that is the
simplest approach - it also means I can use their autodetection code[4]
(still trying to decide if that actually is a good idea or not). Sure,
there are other solutions, I currently think this is the simplest one.
I hope this helps explain the situation, without getting too far off-topic
for this mailing list.
I think the concept of plugins might be relevant to other projects, not
just this one.
Notes
[1] not to be confused with the delicious Japanese meal available from the
restaurant around the corner, or with
https://github.com/karaage-cluster/karaage/ which is a project I maintain.
[2] not to be confused with https://github.com/karaage-cluster/karaage-*/
which are plugins for [1].
[3] not to be confused with https://github.com/vlsci/karaage/ which is a
fork of [1].
[4] autodetection implemented using
pkg_resources.iter_entry_points('karaage.apps'); so it relies on each
plugin being in a separate distributable.
--
Brian May
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
On Thu, Feb 5, 2015 at 6:53 AM, Tianon Gravi wrote: > Checking out http://pypi.debian.net/hy, it looks pretty easy to use. :) Could whoever created this add a page to the Debian services census? https://wiki.debian.org/Services -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6fj8qeq3qegfiec0orrti2lv2mhcmjkdhtvkqhon8u...@mail.gmail.com
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
On Thu, Feb 5, 2015 at 6:53 AM, Tianon Gravi wrote: > Checking out http://pypi.debian.net/hy, it looks pretty easy to use. :) Could someone document this on the debian/watch wiki page please? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gab69_i-fypbceyfgiwirncb4ei2nerlefzwunbvf...@mail.gmail.com
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
On Feb 04, 2015, at 05:25 PM, Donald Stufft wrote: >I'm on my phone currently but I think Barry is using it in the wheel package >now. I put this in wheel's d/watch file just to test it out manually: -snip snip- version=3 http://pypi.debian.net/wheel/wheel-(.+)\.tar.gz -snip snip- But in case you didn't notice, Piotr implemented something truly brilliant. It takes all the guesswork out of your d/watch file, at least if you want to use the redirector. Just visit http://pypi.debian.net//watch and you'll get a d/watch file perfectly suited for your PyPI package. It's a little more complicated than the hand-written one e.g. above, but at least there's no thinking involved! :) I've updated the instructions here with a cute little curl hack: https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204193818.2836c...@anarchist.wooz.org
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
On 5 February 2015 at 01:12, Piotr Ożarowski wrote: >> http://pypi.debian.net/hy.watch > > or better: http://pypi.debian.net/hy/watch Oooh, nice! Now add an option to make it do pgpsigurlmangle ;P -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camckhmsaa_hhtzst1+scjmt-ex1gfxifqpptjhsrava+riq...@mail.gmail.com
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
On Feb 05, 2015, at 12:12 AM, Piotr Ożarowski wrote: >> http://pypi.debian.net/hy.watch > >or better: http://pypi.debian.net/hy/watch Piotr, you are an evil genius. :) Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204183819.749d3...@anarchist.wooz.org
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
> http://pypi.debian.net/hy.watch or better: http://pypi.debian.net/hy/watch -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204231207.gj18...@sts0.p1otr.com
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
> Checking out http://pypi.debian.net/hy, it looks pretty easy to use. :) http://pypi.debian.net/hy.watch -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204230904.gi18...@sts0.p1otr.com
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
On 4 February 2015 at 15:18, Ben Finney wrote: > Great! Can we please have (from you, or whoerver is best position to > write it) a reference on how to use this redirector? Checking out http://pypi.debian.net/hy, it looks pretty easy to use. :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cahnknk3wqcme_bwjpi8c-k469wzvnze3m3d_r2yalnrydd6...@mail.gmail.com
Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)
I'm on my phone currently but I think Barry is using it in the wheel package now. > On Feb 4, 2015, at 5:18 PM, Ben Finney wrote: > > Donald Stufft writes: > >> I suggested to #debian-python that a redirector might be better and >> there is now one at pypi.debian.net. > > Great! Can we please have (from you, or whoerver is best position to > write it) a reference on how to use this redirector? > > I don't know a good location; the Debian wiki doesn't have an obvious > location, redirectors only seem to be mentioned briefly at > https://wiki.debian.org/debian/watch#Uncommon_sites>. > > -- > \ Moriarty: “Forty thousand million billion dollars? That money | > `\must be worth a fortune!” —The Goon Show, _The Sale of | > _o__) Manhattan_ | > Ben Finney > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/8561bhgw2k.fsf...@benfinney.id.au > -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/dd57c9f2-bab9-41b3-ab51-70bd03fde...@stufft.io
Debian uscan redirector for PyPI (was: PyPI and debian/watch)
Donald Stufft writes: > I suggested to #debian-python that a redirector might be better and > there is now one at pypi.debian.net. Great! Can we please have (from you, or whoerver is best position to write it) a reference on how to use this redirector? I don't know a good location; the Debian wiki doesn't have an obvious location, redirectors only seem to be mentioned briefly at https://wiki.debian.org/debian/watch#Uncommon_sites>. -- \ Moriarty: “Forty thousand million billion dollars? That money | `\must be worth a fortune!” —The Goon Show, _The Sale of | _o__) Manhattan_ | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8561bhgw2k.fsf...@benfinney.id.au
Re: PyPI and debian/watch
> On Feb 4, 2015, at 4:32 PM, Stefano Rivera wrote: > > Hi Donald (2015.02.04_22:06:25_+0200) >>> On 4 February 2015 at 06:08, Donald Stufft wrote: If it gets implemented it'll live at /uscan/ because it exists primarily to work around the deficiencies that exist in uscan (Particularly the dificulty in ignoring url fragments). > > Would it be that hard to have fake directory listings on /simple/? > I mean, surely keeping compatibility there is simpler than having a > second endpoint just for Debian. All the data that uscan needs is already on /simple/, you can make uscan work with it. There is one major problem and one small problem: 1. Major: The /simple/ URLs all have a #md5= and it’s non trivial to write a d/watch file that ignores them and uscan doesn’t by default. You can do it but it’s ugly and prone to copy/paste bugs. 2. The URLs on /simple/ point to /packages/, so it requires the 2 arg form of d/watch instead of the single arg form. So you can make uscan work right now with /simple/ (and a few people have) but #1 means that a few of the #debian-python people were not very happy with that solution. I can’t remove/modify that hash without causing issues with pip/easy_install though. Originally I was going to just make a /uscan/ that was /simple/ without the hash, but instead I suggested to #debian-python that a redirector might be better and there is now one at pypi.debian.net. > >> We talked about this in #debian-python and there was concern that a new >> version >> of uscan wouldn’t be in Jessie and then wouldn’t cover the people who need it >> the most. > > Who needs it the most? We could fix it in unstable and backports. The > DEHS data on tracker.debian.org comes from quantz.debian.org. which is > currently using devscripts from back ports. No idea, I’m just repeating what folks said in #debian-python, I have no idea who runs uscan and on what platforms. Between fixing uscan and having a redirector I don’t have an opinion since neither one of those have an impact on what PyPI does. > > >> I don’t know if that’s true or not but I certainly think that uscan _should_ >> ignore anything that comes after a # (similarly to how it ignores anything >> that >> comes after a ?). > > Agreed. > > SR > > -- > Stefano Rivera > http://tumbleweed.org.za/ > +1 415 683 3272 > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20150204213208.ga3...@bach.rivera.co.za > --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c118b6b9-f56e-46be-9a80-c5e934c1f...@stufft.io
Re: PyPI and debian/watch
Hi Donald (2015.02.04_22:06:25_+0200) > > On 4 February 2015 at 06:08, Donald Stufft wrote: > >> If it gets implemented it'll live at /uscan/ because it exists primarily to > >> work around the deficiencies that exist in uscan (Particularly the > >> dificulty > >> in ignoring url fragments). Would it be that hard to have fake directory listings on /simple/? I mean, surely keeping compatibility there is simpler than having a second endpoint just for Debian. > We talked about this in #debian-python and there was concern that a new > version > of uscan wouldn’t be in Jessie and then wouldn’t cover the people who need it > the most. Who needs it the most? We could fix it in unstable and backports. The DEHS data on tracker.debian.org comes from quantz.debian.org. which is currently using devscripts from backports. > I don’t know if that’s true or not but I certainly think that uscan _should_ > ignore anything that comes after a # (similarly to how it ignores anything > that > comes after a ?). Agreed. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204213208.ga3...@bach.rivera.co.za
Re: PyPI and debian/watch
On 4 February 2015 at 13:06, Donald Stufft wrote: > We talked about this in #debian-python and there was concern that a new > version > of uscan wouldn’t be in Jessie and then wouldn’t cover the people who need it > the most. Ah right, that makes sense -- I forgot that we were talking about this specifically in the context of getting some kind of fix into Jessie. ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cahnknk3ccon84fffzhxdkgpsneym7dikaonwkorjnqzzuxa...@mail.gmail.com
Re: PyPI and debian/watch
> On Feb 4, 2015, at 3:02 PM, Tianon Gravi wrote: > > On 4 February 2015 at 06:08, Donald Stufft wrote: >> If it gets implemented it'll live at /uscan/ because it exists primarily to >> work around the deficiencies that exist in uscan (Particularly the dificulty >> in ignoring url fragments). > > This seems like we're building a workaround to a tool we could > theoretically change. :( > > "debian/watch" has a "version=3", which is presumably so that there > can be a "version=4" when deficiencies are discovered -- wouldn't it > be worthwhile to consider revbumping the watch format and updating > uscan to have some improved support for edge cases like this? I know > uscan has some other open bugs too that could use some thought towards > a more flexible format to handle cases like this. We talked about this in #debian-python and there was concern that a new version of uscan wouldn’t be in Jessie and then wouldn’t cover the people who need it the most. I don’t know if that’s true or not but I certainly think that uscan _should_ ignore anything that comes after a # (similarly to how it ignores anything that comes after a ?). That would solve the largest problem, that the URL fragment is hard to remove from the d/watch file. The other problem is that /simple// has files located at /packages/ but I believe that’s not very hard to work around. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bc9910d4-1c34-4856-9f0f-b46a99da1...@stufft.io
Re: PyPI and debian/watch
On 4 February 2015 at 06:08, Donald Stufft wrote: > If it gets implemented it'll live at /uscan/ because it exists primarily to > work around the deficiencies that exist in uscan (Particularly the dificulty > in ignoring url fragments). This seems like we're building a workaround to a tool we could theoretically change. :( "debian/watch" has a "version=3", which is presumably so that there can be a "version=4" when deficiencies are discovered -- wouldn't it be worthwhile to consider revbumping the watch format and updating uscan to have some improved support for edge cases like this? I know uscan has some other open bugs too that could use some thought towards a more flexible format to handle cases like this. ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cahnknk2j1huhddu49nqkzag9vf5opcsj49yuulnuterm3jg...@mail.gmail.com
Re: PyPI and debian/watch
> On Feb 4, 2015, at 11:20 AM, Barry Warsaw wrote: > > On Feb 04, 2015, at 10:53 AM, Donald Stufft wrote: > >> That same page also mentions that qa.debian.org runs a number of >> "redirectors" for sites like SourceForge and GitHub so perhaps a better >> answer is for Debian QA to run a redirector for PyPI instead of PyPI >> implementing a redundant API endpoint with a slightly different layout and >> HTML primarily for Debian. > > +1 > > Cheers, > -Barry Dunno the best way to give this to y'all but I wrote a thing: https://github.com/dstufft/pypi-debian I can transfer it on github or release it on PyPI or whatever. It shouldn't really need any maintenance or anything but I'm probably not going to pay attention to it if it does need any so someone else might want to actually own it. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/363795e0-f96f-423f-b6a6-d3f3fbf76...@stufft.io
Re: PyPI and debian/watch
On Feb 04, 2015, at 10:53 AM, Donald Stufft wrote: >That same page also mentions that qa.debian.org runs a number of >"redirectors" for sites like SourceForge and GitHub so perhaps a better >answer is for Debian QA to run a redirector for PyPI instead of PyPI >implementing a redundant API endpoint with a slightly different layout and >HTML primarily for Debian. +1 Cheers, -Barry pgp1m9Nwp58dg.pgp Description: OpenPGP digital signature
Re: PyPI and debian/watch
> On Feb 4, 2015, at 10:07 AM, Barry Warsaw wrote:
>
> On Feb 04, 2015, at 08:08 AM, Donald Stufft wrote:
>
>> If it gets implemented it'll live at /uscan/ because it exists primarily to
>> work around the deficiencies that exist in uscan (Particularly the dificulty
>> in ignoring url fragments). Everyone else should just use the URLs at
>> /simple/
>> which most systems use with no problem because they can parse the URLs and
>> ignore the URL fragments (or use them for verifying the hash if need be).
>
> I'll just note that I've found the fragments inconvenient in other settings
> too. They aren't very user friendly since (IMHO) they add noise that users
> cutting and pasting urls generally don't care about. They also "feel" odd in
> that the md5 checksum doesn't fit what I think as a typical fragment.
> Traditionally, they are used to point to an anchor (sub-resource) within the
> parent resource. That's not the case here.
>
> http://en.wikipedia.org/wiki/Fragment_identifier
>
> has this to say:
>
> """
> Several proposals have been made for fragment identifiers for use with plain
> text documents (which cannot store anchor metadata), or to refer to locations
> within HTML documents in which the author has not used anchor tags:
>
> As of September 2012 the Media Fragments URI 1.0 (basic) is a W3C
> Recommendation.[12]
>
> The Python Package Index appends the MD5 hash of a file to the URL as a
> fragment identifier.[13] If MD5 were unbroken (it is a broken hash function),
> it could be used to ensure the integrity of the package.
>
> https://pypi.python.org ...
> zodbbrowser-0.3.1.tar.gz#md5=38dc89f294b24691d3f0d893ed3c119c
> """
>
> So even without the uscan incompatibility (which is just one of the two
> factors leading to noisy d/watch file), I think there's some value in
> fragment-less URLs. I understand the checksum isn't being used
> cryptographically here, but maybe thinking ahead to the use of more secure
> algorithms in the future can lead to a more flexible design:
>
> Legacy (if it indeed needs to be kept for backward compatibility):
>
> /simple/foo-x.y.z#md5=blah
>
> then:
>
> /simple/plain/foo-x.y.z
> /simple/sha256/foo-x.y.z#sha256=blah
>
Long term PyPI is going to move away from trying to cram a bunch of information
into a hyperlink and relying on HTML parsing and instead is going to move the
installer APIs over to using something more suited to the task, most likely
JSON. At that point we'll be able to design the API to be more extendable in
this regards since we'll be able to do something like:
{
...,
hashes: {
"md5": "...",
"sha256": "...",
},
...
}
and the client can simply select which hash it wants to use. Long term the
/simple/ API on PyPI will exist only for legacy purposes so people still using
versions of pip, easy_install, etc that only support /simple/ will still be
able to access PyPI.
That doesn't really help uscan at all though since as far as I know uscan has
no ability to parse JSON.
As far as copy/pasting goes, the /simple/ API is an API, it's not designed to
be human consumable but consumable by software. The UI centric pages at /pypi
are the ones designed to be consumable by humans (Although currently PyPI puts
the hash there as well, however Warehouse (aka PyPI 2.0) does not).
The problem here really lies within uscan making assumptions about the
structure of URLs and the content of the HTML on those pages. From looking at
https://wiki.debian.org/debian/watch I'm guessing that it inherited those
assumptions from when FTP was the more common way to distribute files instead
of HTTP(S). That same page also mentions that qa.debian.org runs a number of
"redirectors" for sites like SourceForge and GitHub so perhaps a better answer
is for Debian QA to run a redirector for PyPI instead of PyPI implementing a
redundant API endpoint with a slightly different layout and HTML primarily for
Debian.
One note in that regard is that the /simple/ indexes don't include the .asc
files if someone has uploaded them however the old URLs that debian/watch used
did. If that is something that is needed we could easily add them to the
/simple/ pages.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/246c48b2-9f15-4827-aab4-b574f95a2...@stufft.io
Re: PyPI and debian/watch
On Feb 04, 2015, at 08:08 AM, Donald Stufft wrote: >If it gets implemented it'll live at /uscan/ because it exists primarily to >work around the deficiencies that exist in uscan (Particularly the dificulty >in ignoring url fragments). Everyone else should just use the URLs at /simple/ >which most systems use with no problem because they can parse the URLs and >ignore the URL fragments (or use them for verifying the hash if need be). I'll just note that I've found the fragments inconvenient in other settings too. They aren't very user friendly since (IMHO) they add noise that users cutting and pasting urls generally don't care about. They also "feel" odd in that the md5 checksum doesn't fit what I think as a typical fragment. Traditionally, they are used to point to an anchor (sub-resource) within the parent resource. That's not the case here. http://en.wikipedia.org/wiki/Fragment_identifier has this to say: """ Several proposals have been made for fragment identifiers for use with plain text documents (which cannot store anchor metadata), or to refer to locations within HTML documents in which the author has not used anchor tags: As of September 2012 the Media Fragments URI 1.0 (basic) is a W3C Recommendation.[12] The Python Package Index appends the MD5 hash of a file to the URL as a fragment identifier.[13] If MD5 were unbroken (it is a broken hash function), it could be used to ensure the integrity of the package. https://pypi.python.org ... zodbbrowser-0.3.1.tar.gz#md5=38dc89f294b24691d3f0d893ed3c119c """ So even without the uscan incompatibility (which is just one of the two factors leading to noisy d/watch file), I think there's some value in fragment-less URLs. I understand the checksum isn't being used cryptographically here, but maybe thinking ahead to the use of more secure algorithms in the future can lead to a more flexible design: Legacy (if it indeed needs to be kept for backward compatibility): /simple/foo-x.y.z#md5=blah then: /simple/plain/foo-x.y.z /simple/sha256/foo-x.y.z#sha256=blah etc. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204100749.00106...@anarchist.wooz.org
Re: PyPI and debian/watch
> On Feb 4, 2015, at 3:05 AM, Ben Finney wrote: > > Tristan Seligmann writes: > >> The debian/watch file I wrote for python-nacl (which also verifies the >> PGP signature) seems to work. > > I can't get PGP signature retrieval to rowk (“uscan warning: > pgpsigurlmangle option exists, but the upstream keyring does not exist”) > even with your suggested pattern. > > But I have also written a working uscan configuration:: > > opts="filenamemangle=s/\S+\/([^\/]+\.tar\.gz)#md5=[[:alnum:]]+$/$1/" \ >https://pypi.python.org/simple/python-daemon/ \ >\S+/python-daemon-(\S+)\.tar\.gz#md5=[[:alnum:]]+ \ >debian > > > Barry Warsaw writes: > >> I'd love to be able to have something as simple as: >> >> version=3 >> https://pypi.python.org/simple/mypkg/mypkg-(.*).tar.gz >> >> which is close to what most packages probably use today, modulo the >> base url path. > > That would be great. But remember that the uscan documentation > recommends a tighter matching pattern, so that would be:: > >version=3 >https://pypi.python.org/simple/mypkg/mypkg-(.+).tar.gz > >> I filed a bug against pypa/warehouse so hopefully we can get something >> better before Jessie is released (which is when I think there will be >> more pressure for a better solution, since most packages won't be >> updated during the freeze). >> >> https://github.com/pypa/warehouse/issues/358 > > Thanks very much! > > I'm not a fan of having it live at “…/uscan/” though. This is not > specific to Debian, it's a sensible API design for all. > If it gets implemented it'll live at /uscan/ because it exists primarily to work around the deficiencies that exist in uscan (Particularly the dificulty in ignoring url fragments). Everyone else should just use the URLs at /simple/ which most systems use with no problem because they can parse the URLs and ignore the URL fragments (or use them for verifying the hash if need be). --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fa9f43c5-64c5-4cff-a972-30d162099...@stufft.io
Re: PyPI and debian/watch
On 4 February 2015 at 10:05, Ben Finney wrote: > Tristan Seligmann writes: > >> The debian/watch file I wrote for python-nacl (which also verifies the >> PGP signature) seems to work. > > I can't get PGP signature retrieval to rowk (“uscan warning: > pgpsigurlmangle option exists, but the upstream keyring does not exist”) > even with your suggested pattern. You need a debian/upstream/signing-key.asc with the ASCII-armored PGP keys which will be accepted for signing the release. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMcKhMRseQ1C-kz=ofe9s+9rdfxokrwcfp1pb0qgpsjkagm...@mail.gmail.com
Re: PyPI and debian/watch
Tristan Seligmann writes: > The debian/watch file I wrote for python-nacl (which also verifies the > PGP signature) seems to work. I can't get PGP signature retrieval to rowk (“uscan warning: pgpsigurlmangle option exists, but the upstream keyring does not exist”) even with your suggested pattern. But I have also written a working uscan configuration:: opts="filenamemangle=s/\S+\/([^\/]+\.tar\.gz)#md5=[[:alnum:]]+$/$1/" \ https://pypi.python.org/simple/python-daemon/ \ \S+/python-daemon-(\S+)\.tar\.gz#md5=[[:alnum:]]+ \ debian Barry Warsaw writes: > I'd love to be able to have something as simple as: > > version=3 > https://pypi.python.org/simple/mypkg/mypkg-(.*).tar.gz > > which is close to what most packages probably use today, modulo the > base url path. That would be great. But remember that the uscan documentation recommends a tighter matching pattern, so that would be:: version=3 https://pypi.python.org/simple/mypkg/mypkg-(.+).tar.gz > I filed a bug against pypa/warehouse so hopefully we can get something > better before Jessie is released (which is when I think there will be > more pressure for a better solution, since most packages won't be > updated during the freeze). > > https://github.com/pypa/warehouse/issues/358 Thanks very much! I'm not a fan of having it live at “…/uscan/” though. This is not specific to Debian, it's a sensible API design for all. -- \ “Probably the earliest flyswatters were nothing more than some | `\sort of striking surface attached to the end of a long stick.” | _o__) —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85h9v2gkz5@benfinney.id.au
