Extending option --repo to support arbitrary urls

[CohenCyril]

As it is now, the --repo option does not work for me as I would like to write the following, which fails

$ opam2nix resolve --ocaml-version 4.07.1 --repo coq https://coq.inria.fr/opam/released opam
Fatal error: exception Failure("Can't parse github repo from: https://coq.inria.fr/opam/released")

I can hack around this is using

$ opam2nix resolve --ocaml-version 4.07.1 --repo coq "coq/opam-coq-archive"

But this since this repository regroups three distinct "opam archives" (two of which are dev repositories), this at best is not modular enough, and since I did not manage to make it work, I am not even sure that it detected the three "opam archives"... Moreover, cloning the whole repository takes ages (in my case today, it took more than 15min).
I think your restriction could be broadened to arbitrary urls.

BTW, about local repository, forbidding them completely is problematic for quick-testing and hacking locally, I would prefer a warning stating this is bad practice and shouldn't be shared with the world.

Thanks for making this great tool available anyways.

[timbertson]

Yeah, arbitrary URLs is fair enough, just a bit tougher. The github-only restriction is because it required less code changes, with arbitrary URLs I'll need to change the types for representing repos as well as the nix expression generation (it assumes fetchFromGitHub).

Moreover, cloning the whole repository takes ages (in my case today, it took more than 15min).

That should be only the first time, right? Once you have that repo I think fetching updates should be pretty quick.
(still annoying for the first run though, I've sat through enough nixpkgs clones to know)

BTW, about local repository, forbidding them completely is problematic for quick-testing and hacking locally, I would prefer a warning stating this is bad practice and shouldn't be shared with the world.

The trouble is this might work for selection, but even building locally will fail if you're using sandboxing. Honestly you're likely to have less trouble just making a temporary branch in some public repository, and just keep pushing commits to it. Once you're done fixing problems, you can rebase / clean up the commits to actually make sense.

[CohenCyril]

Hi @timbertson thanks for your answer. Given than the coq opam repository is not organized in the same way ocaml's is, with 3 directories core-dev, extra-dev and released, and only then packages, I did not manage to tell opam2nix to use either one. So I guess my minimal requirement for my usecase would be to be able to select (one or several) subdirectories in addition to the git repo.

[timbertson]

Oh right, yeah that'll be a problem 🤦 . That's less hard to suport than non-github repos at least

[Blaisorblade]

Thanks for filing the issue. FWIW, I tried briefly using opam2nix, but have packages in:

1. repos on gitlab.com ([email protected]:bedrocksystems/formal-methods/opam.git)
2. repos on self-hosted gitlab instances (git+https://gitlab.mpi-sws.org/iris/opam.git)

Some of those are private, but I expect that's my problem; the rest might apply to others.