From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 6DDED1FF16F for ; Thu, 2 Jan 2025 16:54:14 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 785581098E; Thu, 2 Jan 2025 16:54:05 +0100 (CET) Mime-Version: 1.0 Date: Thu, 02 Jan 2025 16:54:00 +0100 Message-Id: To: "Proxmox VE development discussion" From: "Max Carrara" X-Mailer: aerc 0.18.2-0-ge037c095a049 References: <20241220185207.519912-1-m.carrara@proxmox.com> <9e522634-51ff-493a-bcdb-aba560d17d6a@proxmox.com> <47ba1e8e-c5d1-4873-91c4-9927b3b72e8c@proxmox.com> In-Reply-To: <47ba1e8e-c5d1-4873-91c4-9927b3b72e8c@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.045 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH v2 pve-common 00/12] Introduce and Package PVE::Path & PVE::Filesystem X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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