Re: PEP 453 affects Debian packaging of Python packages
On Friday, September 20, 2013 15:44:05 Thomas Kluyver wrote:
> On 20 September 2013 12:08, Paul Tagliamonte <paultag@debian.org> wrote:
> > Don't take this as me trashing on Python or Pythonistas. If you want to
> > talk
> > about this in person, I'm usually at PyCon. I'm also usually in the
> > packaging
> > BOF. Perhaps we can bring some of this up there this year?
>
> Unfortunately, I don't think I'll be going to PyCon next year. I'll
> probably be at next year's SciPy, but I presume you won't be there?
>
> I'm glad to hear that you are a developer as well. However, a lot of the
> tone in this discussion suggests that all developers are idiots who can't
> keep an API intact. I think there is a much more productive conversation to
> be had with upstreams.
>
> > > help. Work with upstream developers to understand what they're doing,
> >
> > encourage
> >
> > > them to care about API stability and to use conventions like semantic
> > > versioning and deprecation warnings to reduce the impact of changes.
> >
> > There are
> >
> > > plenty of developers who do care about backwards compatibility.
> >
> > And just as many (if not more) that don't. As a result, we have to
> > design the system to defend against this breakage.
>
> Alright, a proposal: create some kind of 'expedited upload' pathway, so
> upstream developers sign to say that they will use semantic versioning,
> never break APIs in a bugfix release, issue deprecation warnings for any
> code relying on something that they plan to remove, and create strong
> regression tests. We could add other reasonable conditions to this list.
> The carrot for developers is that, by agreeing to this, they get
> semi-automated uploads of minor updates (run the package's own tests, run
> DEP-8 tests of its dependencies, and a brief manual check). If projects
> that have signed break the requirements, kick them off the pathway for a
> couple of subsequent releases.
>
> At present, there is no carrot - getting stuff packaged is slow whether
> upstream cares about API stability or not.
>
> (I'm sure someone reading is about to point out a reason why this won't
> work exactly as I have described. Don't bother telling me - I'm not really
> expecting this will actually happen. But please try to think of how things
> might change, instead of why nothing must change.)
In cases where the maintainer and upstream have an active relationship, the
maintainer will know which upstreams these are and how quickly it's reasonable
to upload. The problem is the maintainer structure, but that do many packages
are under maintained.
> > > We could also have topic-specific extra repos, so that a user can add,
> >
> > say, a
> >
> > > Python-science repo to get newer versions of some packages by accepting
> >
> > a bit
> >
> > > of extra risk associated with that. Neurodebian offers something like
> >
> > that, but
> >
> > > in general it's hard to set up. Ubuntu PPAs are much easier to get set
> >
> > up, but
> >
> > > don't build for Debian relases.
> >
> > PPAMAIN would be nice for special cases like this, aye!
>
> OK, I searched that term. It's nice to see that Debian is finally
> considering setting up a PPA system. Did anything more happen on that after
> the mailing list thread got sidetracked into security questions?
>
> Elena:
> > there is an UpstreamGuide_ on the wiki:
> So promote it! I'm pretty sure I've never seen that URL before.
>
> > ITP bugs aren't cruft, they are a way to prevent duplication of work,
> > which would lead to even more frustration.
>
> That seems like an unlikely problem in real world cases - how often will
> two people decide to package the same, currently unpackaged, piece of
> software, within the couple of days or so before the first one publishes
> their work.
There's one package I maintain in Debian that, when I went to package it, I
found an old RFP bug (similar to ITP) and was able to make contact and now we
co-maintain the package. The ITP bugs are not just to avoid collisions. They
go to debian-devel where many developers can review them and comment. it's
not rare to see discussion on them that leads to the packager making some
chances in their plans.
> And if it is necessary: make it simple. A web page listing 'things people
> have said they're working on packaging in the last week', with a text box
> to add something, would be easy to implement. Instead, I have to install a
> command line tool, run through several questions, paste it into an e-mail
> client, and then remember to close the bug in the package's changelog. It's
> a double-reciprocating sledgehammer with cruise control to crush an ant. ;-)
The questions are useful. I find reportbug pretty easy to use and there's
certainly no copy/pasting needed.
Scott K
Reply to: