<domenkozar[m]>
siraben yeah, I guess I'll shift even more focus on docs.
<hexa->
so much nix-env usage out there
<siraben>
For me I would say without IRC it would have been very hard to get started with Nix (no one I knew at the time was using Nix either), sometimes I forget how sparse the docs are in certain places
<siraben>
yeah when are we going to remove nix-env haha
<siraben>
but part of is it also users using Nix incorrectly, making the same assumptions as they do with apt, there's only so much the CLI can do to prevent incorrect use
<siraben>
> let a = 5; in with { a = 3; }; a
<{^_^}>
5
<siraben>
lol
<domenkozar[m]>
we just need Nix release and we'll get rid of nix-env :D
<domenkozar[m]>
well 90% of it
<gchristensen>
scary
<gchristensen>
I hope my use is in the 10% :)
<domenkozar[m]>
what part is scary?
<gchristensen>
that my usage of nix-env might no longer work
<domenkozar[m]>
oh, I meant get rid as in replace it with something better, not remove it from Nix source code.
<siraben>
I've seen his arguments re this before, IIUC it boils down to one of Nix's "original use cases" which is imperative package management as well
<sterni>
we can keep nix-env
<sterni>
we just need to remove -i and -u
<sterni>
:p
<sterni>
-q is fine
<sterni>
-ish
<symphorien[m]>
-iA is fine-ish
<siraben>
if Nix documentation is sparse, flakes documentation is...
justanotheruser has joined #nixos-dev
<domenkozar[m]>
heh
<siraben>
OTOH there does seem to be a few users who grokked Nix early, from reading the HN comments
<gchristensen>
I am glad that eelco isn't looking to get rid of use cases
<domenkozar[m]>
siraben: I find it useful to replace such statements with variables
<siraben>
gchristensen: ah, elaborate?
<domenkozar[m]>
A: I'm trying to do basic operation with X and it's breaking terribly. B: we'll that's because it's also supposed to allow Y
stigo has joined #nixos-dev
<gchristensen>
siraben: people have built things on top of Nix, and it would suck for an entire use case that was built on to no longer work
<siraben>
domenkozar: lol I was about to make a similar meta-commentary
<siraben>
gchristensen: right
<siraben>
Hm, maybe at least some sort of message on the first use of nix-env -i about how it's not recommended would be a good start
<sterni>
siraben: unfortunately ppl know about flakes :p
<domenkozar[m]>
you can deprecate nix-env and have it work at the same time
<siraben>
ENABLE_NIX_ENV=1 nix-env -i ...
<sterni>
nix-env would work if it weren't for -u right
<sterni>
nix-env -iA is completely okay
<sterni>
but nix-env -u doesn't remember the attribute paths
<siraben>
sterni: what makes it ok?
<siraben>
I didn't know -u was the problematic
<domenkozar[m]>
It's even worse now, patches to nix-env are not merged because of the new cli, so development wise it's deprecated, while still recommended to users all around
<sterni>
well nix-env -u upgrades stuff in a way you don't want it to since it tries to infer possible updates from derivation names
<domenkozar[m]>
It should be the other way around if anything
<sterni>
which means that it switches nixpkgs attribute
<sterni>
i. e. from jdk8 to jdk14 for example
<siraben>
sterni: yikes, hence that user's breaking nix binary
<sterni>
domenkozar[m]: yeah that's a real problem imo since there is a lot of stuff used already like sri hashes which isn't supported by non experimental CLIs anymore (like nix-hash)
* siraben
finally reads the article
<siraben>
Sounds like a success story to me, company had a mess of a build system before and managed to migrate incrementally to Nix
<siraben>
Heh they're using flakes too
<gchristensen>
depending on a deprecated feature doesn't strike fear in to your heart?
<sterni>
still better than depending on an experimental one
<domenkozar[m]>
there, sunk cost fallacy put into different words
<domenkozar[m]>
that comment is so right that it hurts
FRidh has joined #nixos-dev
<siraben>
documentation is hard, boring and necessary
<gchristensen>
it sort of remains to be seen if investment could fix it
<FRidh>
Somewhat I would say, yes. I am a bit disappointed to see that despite nix(pkgs) is increasingly adopted, there seem very few contributions on this topic.
<gchristensen>
"oh wow look at this great commons"
<domenkozar[m]>
FRidh: you need incentives, as documentation is hard work where fun quickly evaporates
<FRidh>
domenkozar[m]: right, so where is the funding. I mean, I am all for free and open source software but I think nixpkgs is going to stagnate without funding for documentation and more elaborate changes.
<FRidh>
stagnate as in, larger changes won't get in anymore due to the amount of work it takes
<domenkozar[m]>
FRidh: once I make surplus with Cachix it will go into funding documentation
<FRidh>
example: structured attributes, though I hope I am wrong here
<domenkozar[m]>
(as I've said at nixcon 2018)
<domenkozar[m]>
not saying that's the holy grail, but it's a plan I have :)
<sterni>
domenkozar[m]: the first point needs to be redone, the RFC in question has been accepted already as the deadline has already passed for the FCP (04-02)
<sterni>
Nix Is the utlimate devops toolkit is not really an announcement, is it?
<domenkozar[m]>
I put Nix endorsements into that section, even though it's technically not
<domenkozar[m]>
I could call it Announcements & highlights
<domenkozar[m]>
but I don't want to overcomplicate too much
<sterni>
sure
<domenkozar[m]>
thanks for the notice though :)
<abathur>
speaking of docs; I'm sure it's already circulated but I saw part 12 of https://ianthehenry.com/posts/how-to-learn-nix/ on lobsters the other day and noted that it was good perspective for doc work, and I've since looked at part 1 and see that it's an explicit hope/goal the poster has
<FRidh>
domenkozar[m]: 85 FCP has ended and has been accepted.
<FRidh>
or at least is offered for acceptance
devhell has quit [Quit: leaving]
<domenkozar[m]>
abathur: oh wow, that'a gist
<domenkozar[m]>
FRidh: let me fix that :)
<domenkozar[m]>
fixed
FRidh has quit [Ping timeout: 252 seconds]
FRidh has joined #nixos-dev
<FRidh>
oh the new bootstrap is in use now I see
NinjaTrappeur has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 252 seconds]
FRidh has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<ma27[m]>
niksnut: in case you have time for this atm, what's your current take on https://github.com/NixOS/nix/pull/4440 ? I'm both happy & interested in taking this further, but first we should discuss whether the increased memory consumption is fine for better error location in evaluation errors :)
<{^_^}>
nix#4440 (by Ma27, 12 weeks ago, open): [WIP] Miscellaneous improvements for positioning in eval-errors
<domenkozar[m]>
ma27: that PR is really gold, thanks for doing it!
<ma27[m]>
thanks 😊
orivej has joined #nixos-dev
tomberek has joined #nixos-dev
tdeo has quit [Remote host closed the connection]
tdeo has joined #nixos-dev
tdeo has quit [Remote host closed the connection]
<niksnut>
ma27[m]: added a comment
<niksnut>
I think a few % increase is not a problem
<ma27[m]>
ok thanks, will take a look and report back! %)
rj has joined #nixos-dev
tdeo has joined #nixos-dev
cole-h has joined #nixos-dev
rj has quit [Quit: rj]
FRidh has quit [Quit: Konversation terminated!]
vikanezrimaya has joined #nixos-dev
<vikanezrimaya>
Hello! I've been trying something new today, packaging Deno applications. But something seems to be wrong in my functions, because no matter what hash I put in the fixed-output function, it's never the right one. Either Nix gives me another hash or just outright says that the thing I'm building is "not valid". Try it for yourself here (use
<vikanezrimaya>
Please tell me what am I doing wrong because I feel like I am doing something wrong!
<vikanezrimaya>
I just don't know what
orivej has quit [Ping timeout: 268 seconds]
Synthetica has joined #nixos-dev
<tomberek>
vikanezrimaya: noticed there is an EOF line with a tab instead of spaces... that messes up your here-doc... plus there is no install phase.
thonkpod has quit [Ping timeout: 258 seconds]
<vikanezrimaya>
technically the buildPhase should be the installPhase
<vikanezrimaya>
and it doesn't progress to the point where the heredoc issue is relevant, but I fixed it anyway
<Synthetica>
Is there a reason why substituteInPlace and friends don't error when it does nothing? I've forgot to remove it a few times, and it would be nice to get some warning
<symphorien[m]>
sustituteInPlace does warn irrc
<tomberek>
vikanezrimaya: i'm seeing files in rpglib and a mod.ts
<tomberek>
how are you running it?
<tomberek>
i did `nix build .#hello-deno`
<samueldr>
the most likely answer is "because that's how it was authored" for substitute* tools
<samueldr>
and changing it would likely break a lot of things :/
<tomberek>
Synthetica: i was under the impression it does emit a warning
<samueldr>
there's also the case of applying something to a whole tree not caring about misses
<vikanezrimaya>
tomberek: deno run ./mod.ts, but it compiles TypeScript in JavaScript and I'd like to pre-cache it (and in the future, this will also fetch all dependencies and pre-cache them too - that's why a fixed-output derivation is used)
<vikanezrimaya>
Also if this thing builds, there should be a script in result/bin/${pname}
<vikanezrimaya>
and this thing, as far as I know, does not build
<tomberek>
yeah, there's a `rpglib` in there
<vikanezrimaya>
wait, it built for you? but... how?!
thonkpod has joined #nixos-dev
<vikanezrimaya>
what kind of impure mystery is it?!
<{^_^}>
#42761 (by grahamc, 2 years ago, closed): Require 2FA for all committers
<vikanezrimaya>
the whole concept of Nix is supposed to be "if it works, it'll work everywhere, if it doesn't, it will never work unless you change something"
<colemickens>
ok thank you both, I couldn't remember (reading through 118661 atm)
<samueldr>
except for some impurities :)
<vikanezrimaya>
i'm just gonna go rm -rf /nix/store and install Windows instead
<samueldr>
and asking for a fixed-output-derivation allows more impurities in ;)
<vikanezrimaya>
jk I could never leave NixOS
<tomberek>
vikanezrimaya: how are you trying to do a build?
<symphorien[m]>
and the "I forgot to change sha256" issue
<vikanezrimaya>
same as you, `nix build .#hello-deno`
<vikanezrimaya>
i'm gonna collect garbage and see if it helps
<samueldr>
(it shouldn't)
<vikanezrimaya>
then how?!
<samueldr>
but please do :)
<vikanezrimaya>
this is a rabbit hole and I'm falling in deeper and deeper
<symphorien[m]>
maybe compare your .drv hash ?
<vikanezrimaya>
I feel like I'll be learning C++ soon
<vikanezrimaya>
symphorien[m]: oh that's a good idea!
<symphorien[m]>
if one of you can nix copy the .drv to the other, you can even run nix-diff on them
supersandro2000 has quit [Remote host closed the connection]
<vikanezrimaya>
Weird, the drvPath does seem to be different
<vikanezrimaya>
oh wait
<vikanezrimaya>
i forgot to git reset first
<tomberek>
well... your nixpkgs is unpinned
<tomberek>
ah,, but it's in the lock.. should be okay
<vikanezrimaya>
nah the drvPath still seems to be different
<tomberek>
hidden file in hello-deno
<tomberek>
?
<vikanezrimaya>
but flakes are supposed to prune anything not added to git!
<vikanezrimaya>
no hidden files though
<tomberek>
with flakes you can just say `src = ./hello-deno` ... don't need the copyPathToStore
<vikanezrimaya>
oh, then changing the flake.nix would change the hash of the source and the output of a fixed-input derivation, since it caches files' compilation results using paths
<vikanezrimaya>
that's why I need it to be independent from the flake.nix
<vikanezrimaya>
that's why I used copyPathToStore, so it would get stored separately
<tomberek>
i see
<vikanezrimaya>
I hope that makes it fixed-output, but it might not
<vikanezrimaya>
which might cause an error here
<vikanezrimaya>
this is the only thing I could think of
<vikanezrimaya>
sorry, meant content-addressed not fixed-output
<vikanezrimaya>
those are a little bit different terms, aren't they?
<samueldr>
yeah, fixed-output derivations are more of a pinky swear, when it's used for something more than "just getting a file"
<samueldr>
while content-addressed could come from different inputs, but end up being the same output AFAIUI
<vikanezrimaya>
should I make the fixed-output derivation denoCache produce a single file maybe? .tar.xz?
<samueldr>
I knew my phrasing was going to cause confusion :)
<vikanezrimaya>
it totally did
<samueldr>
the issue is not "a single file", but more about having a process doing "stuff"
<samueldr>
e.g. it's fine to expand a tar.gz you curl'd, since there isn't any "processing" that may or may not be impure
<samueldr>
while when you have something like a yarn, a node, a composer, a [python tool], any of those doing "stuff" to the output, the contract starts not making sense
<vikanezrimaya>
essentially your theory is that `deno cache` thingy isn't fixed-output
<vikanezrimaya>
wait no I meant a different word
<vikanezrimaya>
I just forgot it
<samueldr>
that's the general issue with that kind of approach
<samueldr>
reproducible
<vikanezrimaya>
exactly!
<samueldr>
bue fixed-output is also fine here
<vikanezrimaya>
thank you
<gchristensen>
unpacking in the FO is a bit less ideal, though, since your hash won't match the upstream's hash of the tarball, and filesystem normalization can cause hash mismatches on the extracted version
<samueldr>
since fixed output implies it's reproducible!
<vikanezrimaya>
gchristensen: I am the upstream
<vikanezrimaya>
only the second point applies because of that
<gchristensen>
same story though, our hash won't match other people's hashes
<samueldr>
ideally fixed-output shouldn't stray from plain downloads of resources
<vikanezrimaya>
sadly not possible there
<samueldr>
or way harder than it needs to because of the tooling :)
<vikanezrimaya>
maybe my approach isn't the best, I probably should go another way
<vikanezrimaya>
thanks for all the help tho
<vikanezrimaya>
I'll probably leave the repo up in case I return to it
<symphorien[m]>
<vikanezrimaya "sadly not possible there"> I'm curious, what makes deno special?
srk has joined #nixos-dev
<vikanezrimaya>
deno does a lot of processing on things it downloads and it might not be bit-for-bit reproducible, I haven't researched that and I don't have the mental energy to do this right now
* symphorien[m]
googles deno
<symphorien[m]>
ah, js
<vikanezrimaya>
typescript too! built-in compiler and type-checker
<vikanezrimaya>
I want to make Nix and Deno friends but it's hard because of all the downloads
<vikanezrimaya>
though Deno is already awesome (if you don't forget to pin all your dependency URLs to specific versions)
MichaelRaskin has quit [Ping timeout: 240 seconds]
srk has quit [Ping timeout: 268 seconds]
MichaelRaskin has joined #nixos-dev
__monty__ has quit [Quit: leaving]
ScottHDev0 has joined #nixos-dev
ScottHDev has quit [Ping timeout: 240 seconds]
ScottHDev0 is now known as ScottHDev
supersandro2000 is now known as Guest18480
Guest18480 has quit [Killed (rothfuss.freenode.net (Nickname regained by services))]