From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ga1C2-0006jY-UF for guix-patches@gnu.org; Thu, 20 Dec 2018 11:29:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ga1C2-000539-8o for guix-patches@gnu.org; Thu, 20 Dec 2018 11:29:02 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:52410) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ga1C2-00052k-4R for guix-patches@gnu.org; Thu, 20 Dec 2018 11:29:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ga1C1-0006dq-Su for guix-patches@gnu.org; Thu, 20 Dec 2018 11:29:01 -0500 Subject: [bug#33801] import: github: Support source URIs that redirect to GitHub Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87d0pxtciz.fsf@gnu.org> <87woo4qxg7.fsf@gnu.org> Date: Thu, 20 Dec 2018 17:28:42 +0100 In-Reply-To: (Arun Isaac's message of "Thu, 20 Dec 2018 18:37:24 +0530") Message-ID: <87k1k4p3gl.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Arun Isaac Cc: 33801@debbugs.gnu.org Arun Isaac skribis: >> We could maintain a cache of redirects, although that wouldn=E2=80=99t b= e a >> real solution. >> >> Hmm, now that I think about it, shouldn=E2=80=99t we store the github.co= m URL >> directly for these packages? We could add a new lint check along the >> lines of the =E2=80=98check-mirror-url=E2=80=99 procedure that would all= ow us to find >> out which URLs need to be changed. If we took that route, the changes >> you made to the importer would no longer be necessary. :-/ > > On the other hand, if we constrain our updater predicates to not perform > network operations, we would be restricting what we can achieve with > updaters. For example, suppose in the future we have a cgit-updater to > update packages hosted using cgit. The only way to detect that would be > using some kind of network operation. The way our updaters currently > work, we will only ever be able to properly handle centralized platforms > like GitHub, PyPI, etc. And, that's a pity. We can use heuristics in many cases to determine whether an updater applies to a package; most of the time, that=E2=80=99s only based on the UR= L, and it might also work for many cgit instances=E2=80=94those that have =E2= =80=9C/cgit=E2=80=9D in their URL. Then again, I expect that a growing number of packages will be obtained through =E2=80=98git-fetch=E2=80=99, and the updater for such a thing is tr= ivial (interestingly it=E2=80=99s not yet implemented though :-)). So I feel like at present we don=E2=80=99t have strong evidence that that t= he simple URL-based approach would not scale. WDYT? > Another solution, though somewhat inelegant and tedious, would be to add > an `updater' field to the package specification so that the packager can > explicitly specify what updater to use. That could be useful to handle corner cases, but it should remain the exception. Thanks, Ludo=E2=80=99.