0.12.0
(diff) 0.12.0 (2020-01-05)
-
Disclaimer: Current
derivationStrict
primOp implementation and so every evaluation of a derivation into a store path currently relies on thehnix-store-remote
, which for those operations relies on the runningnix-daemon
, and so operations use/produce effects into the/nix/store
. Be cautious - it is effectful. -
Introduction:
- New module
Nix.Effects.Derivation
. - Operations on derivations:
- old got principled implementations.
- also new operations got introduced.
- Implementation of the
derivationStrict
primOp.
- New module
-
Breaking:
- (link)
Nix.Effects
: classMonadStore
got principled implementation.addPath'
got principled intoaddToStore
.toFile_
got principled intoaddTextToStore'
.- For help & easy migration you may use
addPath
&toFile_
addTextToStore
standalone functions in the module.
- (link)
Nix.Effects.Basic
:defaultDerivationStrict
got reimplemented & moved intoNix.Effects.Derivation
. - (link)
Nix.Standard
: instance forMonadStore (Fix1T t m)
got principled accoding to classMonadStore
changes. - (link)
Nix.Fresh.Basic
: instance forMonadStore (StdIdT m)
got principled.
- (link)
-
Additional:
- (link) New module
Nix.Effects.Derivation
: HNix(0.12.0):Nix.Effects.Derivation documentation. - (link)
Nix.Convert
: PrincipledNVPath -> NixString
coercion.- In a form of principled
instance FromValue NixString m (NValue' t f m (NValue t f m))
.
- In a form of principled
- (link)
Nix.String
: Allow custom computations inside string contexts.- By providing
runWithStringContext{T,}'
methods into the API.
- By providing
- (link) Includded support for new
base16-bytestring
, which advertices 2x-4x speed increase of its operations. - (link)
Nix.Effects
:addPath
&toFile_
standalone functions got principled implementation through the internal use of the newMonadStore
type class implementation. - (link)
Nix.Effects
: addedaddTextToStore
,parseStoreResult
implementations. - (link)
Nix.Effects
: added type synonyms{RecursiveFlag, RepairFlag, StorePathName, FilePathFilter, StorePathSet}
. - (link)
Nix.Exec
: Fixed the rendering of internalFrames
.- Which is an internal mechanism of a project to passing around messages with their context, still to be used internally).
- (link)
HNix / Nix
: The library now also useshnix-store-remote
. - (link)
cabal.project
: project usescryptohash-sha512
override, thehnix-store-core
requires it fromhnix
and uses that override also. Detailed info. We promise to attend to this issue, probably by migrating tocryptonite
in the nearest releases.
- (link) New module
Future note: The HNix is a big project. During the initial development and currently the API for simplicity exposes allmost all functions, types, etc. Big open API means a big effort to create/maintain a quite noisy changelog and you parsing through it, and also creates a frequent requirements to mark releases as major and bother you due to some type changes in some parts that may not be used or applicable to be public API.
This year the most gracious API clean-up would happen, we would check and keep open what Hackage projects are using from the API, and the other parts would be open on the request by a way of rapid minor releases. That clean-up is also a work toward splitting the project into several packages some time in the future (split would be into something like Expressions, Evaluation, Executable, Extra), which migration also would be done most thoughful and graceful as possible, with as much easiness and automation provided for migration downstream as possible. If all goes as planned - all downstream would need to do is to get and run our script that would migrate our old map of module imports to new ones, and maybe manually add those newly formed packages into .cabal
description.
If it is possible, please, try to switch & use the higher-level API functions where it is applicable. Thank you.