On Thu Jan 2, 2025 at 2:53 PM CET, Fiona Ebner wrote: > Am 02.01.25 um 14:46 schrieb Fiona Ebner: > > Am 20.12.24 um 19:51 schrieb Max Carrara: > >> Introduce and Package PVE::Path & PVE::Filesystem - v2 > >> ====================================================== > > > > Just an idea, but I'd like to have a discussion about it: Instead of > > using Perl for such new general helper modules, would it be nicer to use > > Rust+perlmod? > > > > If our long-term goal is to migrate the Proxmox VE Perl code to Rust, > > then we need to switch these modules over at some point in any case (or > > drop them after switching over all users of the modules). Are there good > > reasons not to start out with Rust+perlmod already? > >
Depends on what you mean with nicer: I was reluctant to use perlmod here for a couple reasons: 1. We appear to have everything in the pve-rs crate right now (libpve-rs-perl), so I had assumed that if I wanted to use perlmod here, then I'd have to put my implementations into that crate as well. This in turn would mean that for a simple path op library I'd need to pull in pve-rs as dependency, which also contains a bunch of different things that aren't concerned with path op stuff. Perhaps I'm misunderstanding the purpose of the pve-rs crate, but I decided against using perlmod here solely because I didn't want to add any additional dependencies to this library unless otherwise necessary. Right now as of this series, no additional dependencies besides some Perl core modules are needed; the library can exist on its own. 2. I'm uncertain whether we actually want to have multiple repositories or packages using perlmod (instead of having just pve-rs). If we can use perlmod for individual modules, as in, add perlmod *alone* as a dependency for packages like this one, then implement features and add dependencies selectively, I'd be open to it. Perhaps as an example, what I'd ideally prefer is something like Python's cryptography is using PyO3 -- there's a Rust part and then there's a Python part that's using the things implemented in Rust; only whatever's necessary is pulled in [1]. 3. Related to 1. and 2., there isn't any clear indication / guide / rule of thumb / etc. on how perlmod ought to be used and in which contexts it should be used. 4. Should we decide to use perlmod here eventually, individual functions can still be implemented in Rust separately. Right now, there wasn't really a need to use Rust, because PVE::Path works at most with strings and a couple arrays here and there; there are no complex data structures that need to be made typesafe. > > You state that you (also) took inspiration from Rust's `std::path` so > > could we just use that itself, wrapping via perlmod? Or would the > > wrapping be too ugly here or lead to performance issues? 5. I'm not sure about the performance overhead, but it would certainly be somewhat ugly, because all which PVE::Path essentially does consists of string and array operations. If we used perlmod here hypothetically, all that we'd be doing is give the Rust side a string or an array, convert that to a PathBuf / Path or an iterable, perform the requested operation and give the result back to Perl. It just seems a little unnecessary to me. 6. I reckon that the places in which those two little libraries here will be used will most likely be replaced by a pure Rust implementation as a whole -- IMO there's no need to use perlmod for every single smaller library if the Perl code using them gets replaced by Rust. In other words, IMO a top-down approach such as replacing higher-level subroutines or entire API calls would probably yield better results rather than a bottom-up approach. (I believe there's a pattern for this -- strangler pattern? I'd have to look it up tbh) > > Or depending on whether it's nicer, also wrapping helpers from > proxmox-sys and friends where we already have similar functionality in > our Rust code. 7. While I'm a big fan of re-using existing code, I don't think it applies here -- I think it's fine to keep *certain* things separate and decoupled from one another until we actually find that there's a lot of common functionality between two or more things (speaking generally here). For PVE::Path and PVE::Filesystem in particular, we can always bridge over to Rust via perlmod for individual functions if needed (4.) nevertheless, if that even ends up being necessary (6.). With all that being said, I hope I could convey my reasoning here and shine some light on my design decisions -- please let me know what you think! And thanks for having a look :) [1]: https://github.com/pyca/cryptography/tree/7fd5f95354e33d9ca90ba854e9cbda958968043a/src _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
