qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
baka has joined #spectrum
hube has quit [Ping timeout: 265 seconds]
<ehmry> I met some people from the Internet Society last week, and they said the deal would make them more money. something something investments
<ehmry> but on the blockades, I've never met anyone personally who has had problems with github, so its hard to know the extent of the problem
<MichaelRaskin> Hmm, maybe crate2nix would be a good idea for rust-9p/unpfs now…
<qyliss> not sure if my messages aren't getting through of if the log bot isn't picking them up...
<MichaelRaskin> I see a link to an RFC proposal
<MichaelRaskin> That got thhrough
<MichaelRaskin> Maybe submit crate2nix even before RFC submission
<qyliss> oh, cool, it worked
<qyliss> cool
<qyliss> I see. Messages are getting through but very delayed.
<qyliss> Well this will be fun
<qyliss> MichaelRaskin: I figure there must be a reason crate2nix isn't included already? Although I don't know what that could be.
<MichaelRaskin> Looks like there is some soulseeking what to call 1.0, and it kind of works from checkout (but slowly), so nobody gets around to submit it
<MichaelRaskin> I find some stuff packaged using crate2nix, and I see no attempts to submit it
<qyliss> there will be resistence to that rfc fwiw
<qyliss> not sure how to handle that
<tazjin> qyliss: I suspect the resistance there stems more from how carnix generates disjunct dependency sets per application by default
<tazjin> which should be less of an issue if we were to generate them more like we do for other languages and reuse
<tazjin> btw, I'm fairly sure peter (from crate2nix) is at 36c3 so we could do a brainstorming session
<qyliss> I want a quicker fix to this problem
<qyliss> That would be rad in theory, but buildRustPackage is broken now
<tazjin> it's not a large change
<tazjin> fairly sure buildRustCrate already supports doing things that way and the generated files would only need to be slightly different
<tazjin> the main question I have is about dealing with package versions, because providing a consistent set (like haskellPackages.*) is gonna be difficult for Rust (since there's no stackage or anything like that )
<qyliss> Exactly
<qyliss> I think that's a much bigger thing to try to introduce
<tazjin> not if we populate it lazily
<tazjin> e.g. crate2nix writes deps into their own derivations when people package things with missing deps
<tazjin> but we don't preemptively generate a package set
<tazjin> qyliss: I spoke to peter - would you be up for a chat about this some time tomorrow? (he's busy today)
<qyliss> Even so, there's a policy question
<qyliss> I don't think we should package every patch version of every Rust library, for example
<tazjin> no, but all the ones that we need to build the software in nixpkgs
<tazjin> and if we're doing that I'd like to avoid duplication
<tazjin> otherwise we'll have 9 million copies of giant derivations for aho-corasick, serde etc.
<qyliss> tazjin: I might have time tomorrow but difficult to say right now
<qyliss> I think we'd additionally want to avoid packaging, e.g., serde 1.2.0 AND 1.2.1
<qyliss> even if we have packages locked to each
<qyliss> But this feels to me like a step we could take _after_ switching away from buildRustPackage. Having big Cargo.nix files is unsightly, but buildRustPackage is _broken_.
<tazjin> qyliss: agree that we can dedup minor versions later, but per distinct version I'd like to avoid duplication
<tazjin> let me know tomorrow if you have time, I'm trying to stay flexible! :)
adisbladis has joined #spectrum
Gggg has joined #spectrum
Gggg has quit [Remote host closed the connection]
pie_ has joined #spectrum