From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Questions about packaging Date: Thu, 10 Oct 2019 02:41:27 +0200 Message-ID: <20191010024127.1da7c86d@scratchpost.org> References: <20191009095633.qlhnq2yvtp7dbrrf@rafflesia> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/.RljAk=jD73bulaK10NPwWH"; protocol="application/pgp-signature"; micalg=pgp-sha256 Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:46728) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iIMWP-0001Up-G7 for guix-devel@gnu.org; Wed, 09 Oct 2019 20:41:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iIMWO-0001oZ-5g for guix-devel@gnu.org; Wed, 09 Oct 2019 20:41:37 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:35612) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iIMWN-0001oD-QP for guix-devel@gnu.org; Wed, 09 Oct 2019 20:41:36 -0400 In-Reply-To: <20191009095633.qlhnq2yvtp7dbrrf@rafflesia> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Tanguy Le Carrour Cc: Guix --Sig_/.RljAk=jD73bulaK10NPwWH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On Wed, 9 Oct 2019 11:56:33 +0200 Tanguy Le Carrour wrote: > 1) Updating a package > So I=C2=A0would 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 w= ork. > 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 wrote: > As I=C2=A0understand 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 definit= ely 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. --Sig_/.RljAk=jD73bulaK10NPwWH Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl2efjcACgkQ5xo1VCww uqVr9wgAkWBmolxVh0E1opD5+td5nk00e04z/wqlWGrLovr5/d3M3xmOa/BMmNCl XOmD0fiXmqC4WaT/8JnhThvB+TYqjPxsanykS/vAfy3a4zJcR9BmN9PYxPnaIkJL hMMD3r+nUCbhsImtNPSadbkdEFmPie+6X5RqW9YyKak/KOS+K9AqP4IT4EMnA9Ne eP3rZOT0cHGuAZb/6jkWFsdrc+Jzzse2hWsFM9NzIdY9eDI9h1R9vRMYg9VKmcdF ZUoW3YA3sHQoH26waqnReqsu1RwEpd8/L4kEgcDdR9o+MmVSqWWe7pzGq187ggFz 5hWl4d+BZCS1/06vV67pp6pRd+I9yQ== =Kkol -----END PGP SIGNATURE----- --Sig_/.RljAk=jD73bulaK10NPwWH--