racket / pkg-build

Other
5 stars 9 forks source link

Package fails to build when using a web-based package source #14

Open countvajhula opened 2 years ago

countvajhula commented 2 years ago

Packages using a specific older version for a dependency via a valid package source format that relies on a web resource (i.e. hosted Git repo) fail to build on the package server, even though the packages themselves are in conformity with prescribed package management concepts.

The error reported by the package server is:

Querying Git references for qi-lib at git://github.com/countvajhula/qi.git?path=qi-lib#v1.0-maintenance
pkg: Contacting github.com
pkg: Network error; retrying after 0.1s
pkg: Contacting github.com
pkg: Network error; retrying after 0.2s
pkg: Contacting github.com
pkg: Network error; retrying after 0.4s
pkg: Contacting github.com
pkg: Network error; retrying after 0.8s
pkg: Contacting github.com
pkg: Network error; retrying after 1.6s
pkg: Contacting github.com
tcp-connect: host not found
  hostname: github.com
  port number: 443
  system error: Temporary failure in name resolution; gai_err=-3
  context...:
   /home/root/racket/collects/openssl/mzssl.rkt:1935:0: do-ssl-connect
   /home/root/racket/collects/racket/contract/private/arrow-val-first.rkt:555:3
   /home/root/racket/collects/net/http-client.rkt:67:0: http-conn-open!
   /home/root/racket/collects/net/http-client.rkt:274:0: http-conn-open
   /home/root/racket/collects/racket/contract/private/arrow-val-first.rkt:555:3
   /home/root/racket/collects/net/url.rkt:202:0: http://getpost-impure-port
   /home/root/racket/collects/net/url.rkt:305:0: get-pure-port/headers
   /home/root/racket/collects/racket/contract/private/arrow-val-first.rkt:555:3
   /home/root/racket/collects/net/git-checkout.rkt:245:0: initial-connect
   /home/root/racket/collects/net/git-checkout.rkt:55:2: retry-loop
   /home/root/racket/collects/pkg/private/stage.rkt:62:2: lookup-normally
   /home/root/racket/collects/pkg/private/stage.rkt:115:0: stage-package/info
   /home/root/racket/collects/pkg/private/install.rkt:141:0: install-packages
   /home/root/racket/collects/pkg/private/install.rkt:925:4
   /home/root/racket/collects/racket/contract/private/arrow-val-first.rkt:555:3
   /home/root/racket/collects/racket/file.rkt:763:8
   ...
The time is now Friday, June 17th, 2022 12:37:17am

This means that packages that use an officially supported dependency mechanism are incorrectly reported as broken, causing docs and all dependent packages to also be reported as broken.

For some context, the relation package is faced with the choice of either continuing to support legacy Racket code (7.8+) or drop support for <8.3. It could do the former by using a Git ref to a maintenance branch of one of its dependencies (Qi), but currently this runs into the present issue. The other option is to drop support for <8.3 which sweeps it under the rug, but seems a bit extreme.

samth commented 2 years ago

I'm not sure what the issue with the relation package is, but the usual fix here is to use the version-exception mechanism on pkgs.racket-lang.org to specify that old version of Racket should use a different source for relation (usually a different branch in your Git repo).

countvajhula commented 2 years ago

@samth The upstream Qi dependency does use a version exception for older versions of Racket, but there it was unavoidable since the feature used by Qi was simply missing in <8.3. On the other hand, with relation, in principle if I keep adding features to it, there's no reason that older versions of Racket shouldn't have them. Relation itself doesn't use the feature in Qi (viz. macro-extensibility) that necessitated its bump to 8.3+. Being able to depend on an older version in a library would avoid the need to propagate version exceptions downstream to dependencies (a "cancer" of version exceptions), and consequently would also save package maintainers the trouble of maintaining separate branches for bugfix purposes.

samth commented 2 years ago

Then I don't understand the problem. If relation depends on qi using a version specification that is ok with what the qi version exception provides, then why is there a problem at all?

countvajhula commented 2 years ago

Do I need to do something special on the downstream end (i.e. relation's info.rkt) to refer to the upstream version exception? ~Using just qi-lib on Racket 7.8 pulls down the latest Qi instead of the v1.0-maintenance branch listed as version exception: https://github.com/countvajhula/relation/runs/6925339363?check_suite_focus=true~ Ah whoops, looks like I only have version exceptions added for 8.1 and 8.2. I will try adding it for earlier versions too.

countvajhula commented 2 years ago

Adding the version exceptions for earlier versions on qi fixed the build failure with relation on legacy versions 🙂

I leave it to your discretion whether to close this issue or not. Version exceptions work in my case but they are different from the reported issue, and I can imagine cases where the reported issue would still be encountered (e.g. upstream package drops support for something used in a package). Of course, the issue could also be reopened at such a time.

racket-discourse-github-bot commented 2 months ago

This issue has been mentioned on Racket Discourse. There might be relevant details there:

https://racket.discourse.group/t/use-git-directly-for-versioning/2896/6