Maximilian Bosch 35eec921af libfetchers: make attribute / URL query handling consistent
The original idea was to fix lix#174, but for a user friendly solution,
I figured that we'd need more consistency:

* Invalid query params will cause an error, just like invalid
  attributes. This has the following two consequences:

  * The `?dir=`-param from flakes will be removed before the URL to be
    fetched is passed to libfetchers.

  * The tarball fetcher doesn't allow URLs with custom query params
    anymore. I think this was questionable anyways given that an
    arbitrary set of query params was silently removed from the URL you
    wanted to fetch. The correct way is to use an attribute-set
    with a key `url` that contains the tarball URL to fetch.

  * Same for the git & mercurial fetchers: in that case it doesn't even
    matter though: both fetchers added unused query params to the URL
    that's passed from the input scheme to the fetcher (`url2` in the code).
    It turns out that this was never used since the query parameters were
    erased again in `getActualUrl`.

* Validation happens for both attributes and URLs. Previously, a lot of
  fetchers validated e.g. refs/revs only when specified in a URL and
  the validity of attribute names only in `inputFromAttrs`.

  Now, all the validation is done in `inputFromAttrs` and `inputFromURL`
  constructs attributes that will be passed to `inputFromAttrs`.

* Accept all attributes as URL query parameters. That also includes
  lesser used ones such as `narHash`.

  And "output" attributes like `lastModified`: these could be declared
  already when declaring inputs as attribute rather than URL. Now the
  behavior is at least consistent.

  Personally, I think we should differentiate in the future between
  "fetched input" (basically the attr-set that ends up in the lock-file)
  and "unfetched input" earlier: both inputFrom{Attrs,URL} entrypoints
  are probably OK for unfetched inputs, but for locked/fetched inputs
  a custom entrypoint should be used. Then, the current entrypoints
  wouldn't have to allow these attributes anymore.

Change-Id: I1be1992249f7af8287cfc37891ab505ddaa2e8cd
2024-06-22 14:42:43 +02:00
2024-04-08 19:50:24 -07:00
2024-03-29 22:57:40 -07:00
2024-03-29 20:26:38 -07:00
2024-05-24 02:22:44 +00:00
2024-03-29 22:57:40 -07:00
2024-04-08 13:00:00 -07:00
2024-06-18 19:25:58 -07:00
2024-05-27 16:47:40 +02:00
2024-04-08 13:00:00 -07:00

Lix

Lix is an implementation of Nix, a powerful package management system for Linux and other Unix systems that makes package management reliable and reproducible.

Read more about us at https://lix.systems.

Installation

On Linux and macOS the easiest way to install Lix is to run the following shell command (as a user other than root):

$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install

For systems that already have a Nix implementation installed, such as NixOS systems, read our install page

Building And Developing

See our Hacking guide in our manual for instruction on how to to set up a development environment and build Lix from source.

Additional Resources

License

Lix is released under the LGPL v2.1.

S
Description
Working fork of Lix - carries the adaptive load-aware build-remote patch. Upstream: gerrit.lix.systems
Readme
92 MiB
Languages
C++ 74.9%
Python 11.7%
Nix 6.1%
Shell 3.6%
Meson 2%
Other 1.6%