From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B2C37158089 for ; Sat, 23 Sep 2023 14:01:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BABBC2BC08D; Sat, 23 Sep 2023 14:01:06 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7B3CE2BC01B for ; Sat, 23 Sep 2023 14:01:06 +0000 (UTC) References: <5b5dfbfd-9c7d-a26b-65e7-9f8c5e48bb8f@gentoo.org> <87msxfjix6.fsf@gentoo.org> <878r8yjohn.fsf@gentoo.org> <871qeqjmup.fsf@gentoo.org> <678aa655-8de8-4653-b5a0-bd0bfc6a5fc2@gentoo.org> User-agent: mu4e 1.10.6; emacs 30.0.50 From: Sam James To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file Date: Sat, 23 Sep 2023 14:59:15 +0100 Organization: Gentoo In-reply-to: <678aa655-8de8-4653-b5a0-bd0bfc6a5fc2@gentoo.org> Message-ID: <875y412dlt.fsf@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: ced1988b-a1ad-4478-9d98-497ad69c34d2 X-Archives-Hash: eda2ca5237d94e15d18b99883dee0b5d Arthur Zamarin writes: > [[PGP Signed Part:Undecided]] > On 22/09/2023 17.50, Alex Boag-Munroe wrote: >> On Fri, 22 Sept 2023 at 15:37, Sam James wrote: >>> >>> >>> Alex Boag-Munroe writes: >>> >>>> Any reason for the parseable parts to not be in an established human >>>> readable/editable format? e.g. the config ini style format, or TOML? >>> >>> The only issue really is that depending on how it's done (do we do >>> it for the whole file, or just comments), it may need a new (profile) >>> EAPI which will take a while to implement and deploy. >>> >>> If it's just for comments, then we can do it immediately though. >>> >>>> >>>> To crib from the OP example with something configparser understands: >>>> [PREAMBLE] >>>> Timestamp: 2023-09-21 15:07:42+00:00 >>>> Author: Arthur Zamarin >>>> Justification: Very broken, no idea why packaged, need to drop ASAP. >>>> The project is done with supporting this package. >>>> Bugs: 667687, 667689 >>>> Removal Date: 2023-10-21 >>>> Packages: dev-lang/python >>>> >>>> The format is well documented already and simple to check for >>>> validity, so any GLEP would just need to cover correct keys/values. >>>> >>> >>> But yeah, I agree it's worth thinking about a proper format rather than >>> fragile text mangling going into the future. >>> >> Perhaps eventually it could/should be used for the whole file but as >> an interim/beginning there's no reason you couldn't start with >> comments: >> >> # [PREAMBLE] >> # Timestamp: 2023-09-21 15:07:42+00:00 >> # Author: Arthur Zamarin >> # Justification: Very broken, no idea why packaged, need to drop ASAP. >> # The project is done with supporting this package. >> # Bugs: 667687, 667689 >> # Packages: dev-lang/python >> dev-lang/python >> >> This simply adds a pre parse step of stripping the comments then >> feeding directly into configparser or probably more suitable, TOML >> since TOML has better syntax for directly delivering things like a >> "Packages:" key as a list. >> >> Redoing a bunch of package.* parsing probably wasn't in scope of the >> OP but I've always wondered and this felt an opportune moment to >> ask/suggest :) > > Thanks for the idea. Yes, it was out of scope such suggestions for me > originally, but thinking more about it, I take it more positively. > Please let me (and others) to consider it for some days, cause this is > very interesting proposal. Things to consider is how much effort it is > to file in future, which format to use, etc. > It's fine with me if we just go with the original for now, but I think the awkwardness (which is not your fault, but the nature of wrangling free-form text) of the specification shows that we should at some point move to something structured. But I don't consider it a blocker for doing something better than the status quo. Maybe we'll be better off just going straight for Exherbo-style p.mask in future: https://ciaranm.wordpress.com/2011/03/27/classifying-repository-masks/ Ultimately, text munging sucks and there's only so much we can do to polish it. But your original proposal is a good improvement on how things are now. >> -- >> Ninpo >>