<peti>
domenkozar: Yay! It came out yesterday. And not one day too early. Lts-11 was getting old, really. It's a shame that ghc 8.6.1 is just around the corner, and then lts-12 will be outdated'ish again just a couple of weeks after its release.
ikwildrp1pper is now known as ikwildrpepper
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
<domenkozar>
peti: yeah and most things weren't bumped
<domenkozar>
lots of improvements to be made to the process :)
<domenkozar>
peti: would you be opposed to cabal2nix refactoring such that it would allow better use of it as a library?
<domenkozar>
for example right now we have cabal2nixWithDb
<domenkozar>
I'd like to refactor into cabal2nix :: Options -> ...
<domenkozar>
and cabal2nix' :: Settings -> ...
<domenkozar>
and have Options for cli parsing and then Settings be haskell configuration
<domenkozar>
for example, hackage-db for options would be a path
<domenkozar>
for Settings it would be Hackage type
<peti>
domenkozar: I am hugely in favor or cleaning up that code. A lot of it is very ad hoc'ish. The only thing I'd suggest to do it incrementally in small steps and to coordinate the change before it's implemented because I have some ideas of my own and I'd like to make sure beforehand that those don't conflict.
<domenkozar>
great
<domenkozar>
I'll code up something that only introduces Settings and defaultSettings and let's go from there
<clever>
angerman has also made Cabal2nix, which translates conditional statements in the cabal file into nix if statements
<domenkozar>
yeah the adhockery has reached hocking levels
<peti>
domenkozar: Personally, I want to throw out a lot of the functionality that's currently included in cabal2nix. IMHO, it was a mistake to introduce all those "fetchers" into it, for example. As far as I am concerned, cabal2nix 3.x will convert a local Cabal file to a Nix expression, but no more of that funky "download from github" stuff.
<peti>
clever: Yes, I saw that.
<angerman>
peti: could just take off from the cabal-to-nix in nix-tools ;-)
<domenkozar>
yeah Cabal2nix is the way forward, but it's more like a PoC compared to current infrastructure
<domenkozar>
it lacks all the tooling around it :)
<domenkozar>
peti: I partially agree, I think fetchers are useful, but they should be implemented explicilty
<domenkozar>
right now cabal2nix just tries them in order, but rather cabal2nix could accept --fetcher git
<domenkozar>
etc
<clever>
another thought i had, why not have stack2nix run super.callHackage "vector-sized" "1.0.3.0" {};
<clever>
then you can just omit the data that nixpkgs already had
<domenkozar>
it uses IFD
<clever>
or would that result in a ton of IFD and worsen the performance?
<clever>
ah
<domenkozar>
would be interesting to measure evaluation performance, but I'd say it makes things wrose
<domenkozar>
worse*.
* peti
believes that going forward without IFD is just plain silly. That particular feature solves so many problems we currently have.
<peti>
The fact that we commit megabytes of generated code into the repository makes no sense.
<domenkozar>
I'm hoping hnix can have saner IFD implementation
<peti>
Well, Nix's IFD implementation is okay, IMHO. The only problem is that it lacks a strategy for dealinig with IFD in restricted mode.
<clever>
also, IFD interacts poorly with min-free and max-free based auto-gc
<clever>
the IFD can trigger a gc, which eats things the current eval was about to grab a lock on
<domenkozar>
IFD as-is has many dark corners
<domenkozar>
suddenly cli args to nix stop working, etc
<domenkozar>
but if we don't use it much, it won't improve :)
<domenkozar>
angerman: does Cabal2nix succesfully output stackage snapshot and build it?
<peti>
We already know a reasonable way forward, IMHO: in restricted more, import all derivations that exist and ignore those that don't exist. But there's no implementation. :-(
<peti>
s/more/mode/
<angerman>
domenkozar: well... I use it with cardano. It doesn't run the stackage solver but does an approximation.
<domenkozar>
angerman: does it cross-compile cardano?
<clever>
domenkozar: yeah, we now have node and launcher running, but daedalus cant connect
<domenkozar>
peti: yeah, I think Eelco will pick that up.
<domenkozar>
clever: nice
<angerman>
domenkozar: yes. clever was quite clever in helping set that up :-)
<clever>
all TH runs under wine via iserv
<angerman>
It's pretty close to how ghcjs does it by running the runner (iserv alike) in a nodejs process.
* peti
can't wrap his head around Michael Snoyman's strategy for developing libraries. That guy writes some library A. Then he realizes that he'd prefer some different API, but instead of updating A he then releases a new library B. Then he maintains both A and B in parallel and uses both of those in his own projects, until eventually a new API emerges that's released as C. Now, once C is there, he
* peti
deprecates both A and B. Meanwhile, he realizes that some other API would be cool and starts releasing D. The result of all that is that he's responsible for some 1e300 packages on Hackage, at least half of which are deprecated, and the other half is evenly divided between alternative Preludes, exception handling, and I/O functions.
<domenkozar>
yeah I think conduit also has about 4 different interfaces
<gchristensen>
my concern around the NUR has been around exactly this happening, which I understand is basically "sure, it could happen" and seeing this I'm thinking "duh, of course there is, it is inevitable"
<gchristensen>
"OK but the tag line is asinine. As a regular user of a Linux distribution it is actually impossible for me to take the time to do a full analysis on every package I install to get work done.SOME level of trust has to be there or else the whole idea of a Linux distro can’t work."
<gchristensen>
this comment specifically makes me concerned
<gchristensen>
people _trust_ the AUR because it is supported by Arch, and we must be vigilent in not violating the trust we've accumulated
<Profpatsch>
adisbladis[m]: Is there a metarepository that has git submodules for all packages? :)
<adisbladis[m]>
The current nixpkgs models makes for better testing imo
<Profpatsch>
(don’t tell me packages can use whatever version control they wint)
<Profpatsch>
*want
<adisbladis[m]>
I remember that being a pain point of mine in exherbo because of the different repos
ckauhaus has joined #nixos-dev
<adisbladis[m]>
Profpatsch: Not really iirc
<adisbladis[m]>
No one thing exherbo did right is enforcing git
<Profpatsch>
+2
<Profpatsch>
*+1
ckauhaus has quit [Ping timeout: 240 seconds]
ckauhaus has joined #nixos-dev
ckauhaus has quit [Remote host closed the connection]
ckauhaus has joined #nixos-dev
ckauhaus has quit [Ping timeout: 244 seconds]
ckauhaus has joined #nixos-dev
ckauhaus has quit [Ping timeout: 264 seconds]
Jackneill has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
Enzime has joined #nixos-dev
<gchristensen>
maybe we could do an experiment where we turn on CloudFront's APAC region and see how much it costs
<gchristensen>
monitor the bill and turn it off whenever if it starts to look bad
<adisbladis[m]>
gchristensen: Do we have any stats now so we can get a rough idea of what the distribution looks like?
<gchristensen>
not sure what the stats would look like, but we have all the logs cloudfront provides
<gchristensen>
access to those are tightly controlled (read: eelco can look and nobody else I think ;)) for privacy so I think to get some interesting data out we'd need to provide him a program to manipulate it in to giving the answer you want
<adisbladis[m]>
Ok :) Sounds doable
<gchristensen>
(note: I have no idea if this is realisticly something which would be done, but I think if it can be done, this would be how it would be done)
ekleog has quit [Quit: WeeChat 2.0]
ekleog has joined #nixos-dev
pie_ has joined #nixos-dev
Sonarpulse has joined #nixos-dev
disasm has quit [Ping timeout: 240 seconds]
Jackneill has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
FRidh has joined #nixos-dev
disasm has joined #nixos-dev
Sonarpulse has quit [Ping timeout: 244 seconds]
Sonarpulse has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 268 seconds]
ckauhaus has joined #nixos-dev
ckauhaus has quit []
FRidh has quit [Quit: Konversation terminated!]
orivej has joined #nixos-dev
<thoughtpolice>
gchristensen: Oh, it's certainly doable. I'm pretty sure you can just directly use AWS RedShift directly, since I think the CloudFront logs are just stored in S3 anyway.
<thoughtpolice>
It would probably be more ideal to do something like have an AWS spot instance do some batch processing every day or something and submitting the calculated artifacts offsite. We really don't need much data out of the logs other than "Number of times this object was hit" and various rollups based on that.
<sphalerite>
oh yeah, I've mentioned it a couple times in #nixos now but not here yet: I want to get rid of packageOverrides. Opinions welcome: https://github.com/NixOS/nixpkgs/issues/43266