Re: Questions about packaging

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 2964 bytes --]

Hi,

On Wed, 9 Oct 2019 11:56:33 +0200
Tanguy Le Carrour <tanguy@bioneland.org> wrote:

> 1) Updating a package
> So I would have to update python-cachecontrol from 0.11.6 to 0.12.5.
> Should I create a python-cachecontrol-0.11.6 and fix all the packages
> that depend on it? Only the one that would break?

The latter.  That's one of the things we do at Guix but I would not do at work.

> Btw, python-cachecontrol seems to be broken. I'll work on that. But
> before I'll have to find an answer to question 3.

Then the answer is to update it, and to update everything else that
depends on it (since it didn't work anyway, what's the harm?  The situation
can only improve).

But it seems the breakage is quite generic:

>Failed: [pytest] section in setup.cfg files is no longer supported, change to [tool:pytest] instead.
>command "py.test" "-vv" failed with status 1
>note: keeping build directory `/tmp/guix-build-python-cachecontrol-0.11.6.drv-0'

On Wed, 9 Oct 2019 11:56:33 +0200
Tanguy Le Carrour <tanguy@bioneland.org> wrote:

> As I understand it, to make sure that a package works with the
> dependencies provided by the distrubution (Guix), tests must pass!

Well, it's better if the tests pass, yes.  If the tests fail that's definitely
bad.  If you absolutely can't get the tests to execute in the first place, let's
talk about it (with upstream if necessary).

> So I guess that one should always make sure that the tests can be
> executed from the Pypi download, or use Git to get the sources.

I'd use git (and a tag).  There's no downside that I can see.

> 3) Deactivating tests on purpose
> In my case, python-poetry depends on python-cachecontrol which tests
> depend (for some weird reasons) on Cherrypy. Cherrypy is a (large)
> web framework and has a lot of dependencies!
> In that case, is it OK to disable python-cachecontrol's tests?

If it's only use or two tests that require cherrypy, maybe disable those
if they aren't important (by using "substitute*").

> Or would it be better to ask one of the project to drop one of the
> dependency?! (Poetry dropping CacheControl, or CacheControl dropping
> CherryPy)

That would be a lot better long term--additionally, you could do that in
any case.  Usually upstream has no idea of the huge dependency tree they
cause, so you first have to convince them why it's a bad idea to do that.

> 4) Submitting an incomplete patch series
> Having run into those problems, I'm a bit stuck with a pile of
> patches. Some of them could be submitted. Should I submit them
> separatly?

If they can be used on their own, I post a normal patch series with those
(it usually has a subject "Prepare for ..." or similar).

Otherwise my own personal policy is if keeping what I did in my head is too
difficult, I submit a "WIP" series.  If there are some patches of that
series that can be merged, I usually comment on those additionally.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]