| 27 Apr 2025 |
|  n8henrie joined the room. | 23:11:04 |
| 28 Apr 2025 |
|  chvp left the room. | 14:30:22 |
| 29 Apr 2025 |
|  @yaya:uwu.is left the room. | 11:21:45 |
|  @federicodschonborn:matrix.org changed their display name from This LEGO® Worm™ is licensed under the terms of the he/him or they/them pronouns, at your choice to This legally distinct plastic brick is licensed under the terms of the he/him or they/them pronouns, at your choice. | 14:41:15 |
|  anji joined the room. | 19:11:31 |
| n8henrie | Didn't get any bites in the main channel --
I've been hoping to get this PR working for darwin -- a python / rust (via maturin / PyO3) project that I think just needs to enable the system feature of the libffi-sys crate (same fix as https://github.com/NixOS/nixpkgs/pull/368102).
Unfortunately in this case the libffi-sys crate is a few dependencies deep, and the parent packages don't expose any feature flags to enable libffi/system (which enables libffi-sys/system):
$ cargo tree -i libffi-sys
libffi-sys v3.2.0
├── deno_ffi v0.190.0
│ └── deno_runtime v0.211.0
│ └── vl-convert-rs v1.7.0 (/private/tmp/nix-build-python3.12-vl-convert-python-1.7.0.drv-0/source/vl-convert-rs)
│ ├── vl-convert v1.7.0 (/private/tmp/nix-build-python3.12-vl-convert-python-1.7.0.drv-0/source/vl-convert)
│ └── vl-convert-python v1.7.0 (/private/tmp/nix-build-python3.12-vl-convert-python-1.7.0.drv-0/source/vl-convert-python)
└── libffi v4.0.0
└── deno_ffi v0.190.0 (*)
Any suggestions for enabling this feature flag a few dependency layers deep?
| 19:41:12 |
 Alyssa Ross | I think you can do it by setting it in the top level Cargo.toml | 19:42:59 |
 @r522:matrix.org | if it's not exposed, you can take a dep on libffi-sys directly yourself, and set the feature there
(that's more fragile since you need to use the same version as exists in the dependency, ideally the dependencies would let you pass the system feature)
| 20:52:24 |
| n8henrie | In reply to @qyliss:fairydust.space
I think you can do it by setting it in the top level Cargo.toml I'll try, thanks! | 21:53:39 |
| n8henrie | In reply to @r522:matrix.org
if it's not exposed, you can take a dep on libffi-sys directly yourself, and set the feature there
(that's more fragile since you need to use the same version as exists in the dependency, ideally the dependencies would let you pass the system feature)
Do you mean a nix dependency? Or in cargo.toml as suggested by Alyssa Ross? | 21:54:32 |
| @r522:matrix.org | in cargo.toml, yeah | 21:54:58 |
| 30 Apr 2025 |
 Randy Eckenrode | Can you modify the crate source in rustPlatform.fetchCargoVendor? | 00:26:52 |
| Randy Eckenrode | * Can you modify the crate source in rustPlatform.fetchCargoVendor to enable the feature? | 00:26:59 |
| n8henrie | In reply to @reckenrode:matrix.org
Can you modify the crate source in rustPlatform.fetchCargoVendor? I tried tinkering around in the vendor directory but it made cargo in my nix-shell unhappy. I will try again, and see if I can find examples of this approach. | 01:02:08 |
|  sheeldotme joined the room. | 14:20:07 |
|  @saiko:knifepoint.net changed their profile picture. | 16:18:19 |
| n8henrie | Alyssa Ross 522 Randy Eckenrode think I got it! Thanks for the pointers. https://github.com/NixOS/nixpkgs/pull/397233#issuecomment-2843354952 | 21:46:48 |
| 1 May 2025 |
 Toma | https://github.com/NixOS/nixpkgs/pull/373541
Anyone have anything against this PR? | 00:25:44 |
|  jaen joined the room. | 14:17:29 |
| jaen | Hello, anybody knows if there's a way with Crane (or anything else, really, it's just what I started out with) to have two separate Crago projects, repos/dep and repos/app and have it somehow provide dep to app when doing cargo build without having to change it to a path dependency in Cargo.toml? I've seen something about registry injection in the docs, but it seems that only works for actual, hosted registries and I don't see a way to inject a dependency built separately that way. And so far haven't found anything promising other than that yet. I'm basically trying to see if I can develop two (or more) things side-by-side without forcing any of the projects to be aware of the other at Rust level (my nix setup is external to the projects), so I don't have to worry about accidentally sending some local changes upstream. | 14:17:58 |
| jaen | Also, incidentally, anybody has a good guide/flowchart/checklist/something that makes it easier to know how to structure your data in Rust, especially in a concurrent setting? I've been following the language from back when it was still written in OCaml, so I'd say I have a reasomable high-level understanding of it's concepts, but I also never ended up writing anything non-trivial in it, so I haven't really developed a practical intuition for all those concepts. And when you're trying to write something non-trivial it quickly gets painful — is reference enough in this case or not, should I keep annotating things with lifetimes until it compiles or is that overkill, it seems I'm running afoul of the "multiple immutable XOR single mutable" thing should I maybe use some smart pointer type instead or refactor the code and if so then how, okay I guess I should use Arc<RwLock<_>> but now I have borrow_mut() littered everywhere and for some reason it still thinks my lock guard lives longer than it feels to me it does. This kind of stuff. If there's anything that got any of y'all over this hump and into actuall knowing how to work with the language to structure your data properly, I'd appreciate links. | 14:18:07 |
 Charles | For general rust stuff you may be interested in joining #rust:matrix.org | 18:20:03 |
| Charles | For the first message maybe you just want to use cargo's git dependencies feature to depend on the stuff from the other repo | 18:21:02 |
| Charles | It's not really clear to me what exactly you're trying to achieve. You have two unrelated git repos with rust projects and you want to tie them together in a third repository with nix code? | 18:22:28 |
| Charles | * It's not really clear to me what exactly you're trying to achieve. You have two unrelated git repos with unrelated rust projects and you want to tie them together in a third repository with nix code? | 18:23:07 |
|  PhiliPdB joined the room. | 19:26:25 |
|  Rosuavio changed their display name from Rosario Pulella to Rosuavio. | 20:09:25 |
| jaen | Managed to get some tips on one of Rust discords, so feel a bit unstuck there, hopefully that sticks. For the latter, yeah, kind of. To maybe make this more concrete, I want to try to work on building Android with dynamic derivations — so there's nix-ninja, which uses n2, a ninja successor in Rust and possibly I will need to make some improvements to crates it uses (e.g. the memmap2 crate) and ultimately there will be some nix code, that uses all this to build Android incrementally with nix. The nix part will use nix-ninja, that's pretty simple, just export the binary under packages and use that in the nix code, but it will in turn use n2 as a library and similarly for any dependencies I want to improve. I don't control any of that code (except whatever nix I will write) and I hope to be able to upstream as much as possible, so I want to avoid making any changes to the repos that won't be upstreamable and I'd have to rebase over and over again to keep them. Not too fond of having to keep pushing my changes to a repo, instead of working with them locally either. Which is why I thought I could try to leverage nix to somehow tie them together in a meta workspace of sorts, but so far I haven't seen an easy way to tell crane "see, this crate that I have in a git submodule at repos/n2 wants to use memmap2 from there, but can you instead inject a crate built from repos/memmap2 you have locally?". Hopefully that makes more sense now? | 20:40:22 |
|  oak 🏳️🌈♥️ changed their display name from oak - mikatammi.fi to oak 🫱⭕🫲. | 23:18:16 |
| 3 May 2025 |
|  Rucadi joined the room. | 18:19:13 |
