Since the formatter always depended on devShell packages, building the
formatter involved building all the devShell packages, which can be
slow.
In the case where formatters are set to plain strings, such as
"nixpkgs-fmt", depending on the devShell packages is necessary in order
to put the formatting utility on the path. But when a formatters option
is set to an package, such as "${pkgs.nixpkgs-fmt}/bin/nixpkgs-fmt",
then that formatter option does not depend on the devShell packages.
Flakelight now detects if any of the configured formatters are using the
first form, and only if so does it add the devShell packages dependency.
This allows the first form to still work, without incurring a cost for
flakes that only use the second form.
Users can use the second form for all formatters options if they wish to
not build the devShell packages when using the formatter.
A user whose flake only has a package would expect it to be used when
running `nix develop`. But since theres probably an automatically
created devShell, the package's deps will not be available in the shell.
If a default package exists, it makes sense for its deps to be available
by default in the default devShell.
`devShell` accepted either a package def, a submodule value, or a
function to a submodule value. `devShells` only accepted package defs.
This brings all the options of `devShells` to any devShell configured
with `devShells`.
`nullOr`'s merge function requires definitions to all be null or all be
non-null. It was being used where the intent was that null be used as a
value representing unset, and as such the merge should return null if
all definitions are null and ignore nulls otherwise. This adds a type
with that merge semantics.
Before, devShell could be set to a submodule config, a package def, or a
function taking module args and returning a submodule config. This
changes the last form to take the package set instead.
This enables cleaner configuration by not needing each option to
individually be a function of pkgs. Passing pkgs also gives more
flexibility as all the module args are available under the `moduleArgs`
attr.
Code that relied on module args not directly in the package set will now
have to access them from the `moduleArgs` attr.
If a package uses `pkgs` and tries to get a non-existing package, there
will be an uncachable error. As we cannot control this, this method
needs to be removed. Instead of using this method, the mocked pkgs
should be extended to support more cases.
If a package depends on a package with same name, this causes an
infinite recursion as it tries to depend on itself. This is not likely
what was intended, and breaks ability to re-export packages, so instead
if a package depends on the same name, that now refers to the previous
version.
Previously null was used when a value could not be loaded. This
prevented setting a value to null using a nixDir auto-load.
This change removes the use of null as a special value when loading from
nixDir, allowing it to be used as a normal value.
This removes the manual configuration of which options are auto-loaded.
Now all options are eligible except for "nixDir" and "_module" as those
would cause inf recursions.
Additionally, instead of setting name aliases in the nixDir module, a
config option is added, enabling other modules to extend the aliases
lists.
Many attributes can take moduleArgs when auto-loaded in order to
facilitate access to them from other files. Those same attributes could
not take moduleArgs when included directly, which was inconsistent.
With this change, all attributes that could take moduleArgs when
auto-loaded can now always do so. Auto-loading no longer needs special
cases.
This edge case was inconsistent between setting outputs directly and
auto-loading. Setting directly did not support args, so just merged
sets, thus resulting in a __functor flake output. When autoloading, a
set with a __functor attr was treated as a function and passed module
args.
To correct this inconsistency, outputs now always supports taking args,
and has the autoloading behavior.
Code that relied on previous behavior is easy to fix, as the value needs
to be converted to a function, which can then return the set with
__functor.
optFunctionTo results in a function which needs to be called when using
the option value. This is needed when the argument is not known when
building types (such as with pkgs). When the args are known (for
example, moduleArgs), this leads to more complex code than just calling
the function and resulting in the target type. optCallWith does the
latter.
Previously, devShell was inconsistent when setting it to a function.
When setting directly, a function was assumed to be a package definition
and was used to set devShells.default directly. When auto-loading, a
function was assumed to take module args, and result in config (not a
derivation).
This now enables both behaviors in either case by detecting if a
function is a package definition or if it expects module args and
handling it accordingly.
Instead of having to call the configuration generation functions, the
params can just be set, and the functions will be called automatically
with additional useful settings automatically set.
The `propagationModule` config option provides a module that can be used
to propagate flakelight configuration into other module systems such as
NixOS or home-manager.
Previously, the packages outputs would be evalutated using callPackage
on the package set, but the package set already contains the package. If
another package depends on it, the dependency would be the version from
the package set. By grabbing the packages from the package set, each
package only needs to be evaluated once.
Since evaluating pkgs is expensive, this speeds up evaluation of flakes
with `packages.default` by attempting to get the name using a pkgs set
containing only mocked builders that just return the name.
In order to speed up evalutation of flakes setting `packages.default`,
this trys to compute the pname in multiple ways, ordered by speed. The
pname can be set manually, which is fastest. To avoid computing a new
nixpkgs and flakelight overlays, the second option just uses callPackage
from stock nixpkgs. If that fails, the prior, most accurate, method is
used which creates a new nixpkgs with all the overlays available.
Using `perSystem` to implement per-system attributes ties all the
per-system attributes together; all the `perSystem` functions must run
to determine output attrs. By generating them separately, the generation
can be done lazily.
The set of args passed to modules is useful for more than just
autoloading. This renames it appropriately and makes it available
through pkgs arguments as well.
The formatter uses `devShell.packages` for its path which is not
available when devShell is null. A default value of empty list should be
used when devShell is null.
Using a submodule for devShell removes the need to make every option
nullable and the need to check all of them. By using nullOr submodule,
we can tell if the value has been set and have default values for
options.
This also enables enabling a devShell with no options set.
NixOS build checks significantly slowed down `nix flake show` as it
prints out the derivation names, which for NixOS derivations requires a
large amount of evaluation. By wrapping the derivations, we now give
them trivial names. The NixOS configurations are still built when
running checks as they are a dependency of the wrappers.
In addition to a regular bundler of the form `x: x`, this allows setting
bundler options to a function of the form `pkgs: x: x` which is passed
the package set for the system (for example: `{ hello, ... }: x: hello`
to always return hello). This allows, in particular, an autoloaded
bundler in its own file to access the package set.
This is non-trivial as we must tell `x: x` and `pkgs: x: x` apart.
Fortunately, given some derivation `drv`, `pkgs // drv` is a valid
derivation and a set with attr names matching pkgs. When applying this
to the function, if it returns a derivation, it was of the `x: x` form,
and if it returns a function, it was of the `pkgs: x: x` form.
In order to prevent IFD when evaluating the flake if the bundler is of
form `x: x` and uses IFD, we determine the form and apply pkgs when
applying the bundler instead of during flake evaluation. This is done by
wrapping the bundler.
Of note, we cannot rely on `builtins.functionArgs`, since
`pkgs: { hello, ... }: (x: hello) pkgs` is the same as the inner
function but with args hidden.
