Wed, 05 Jul 2023 23:59:22 +0200 configitems: move blackbox's config items to the new configitems.toml
Raphaël Gomès <rgomes@octobus.net> [Wed, 05 Jul 2023 23:59:22 +0200] rev 50765
configitems: move blackbox's config items to the new configitems.toml In order for the Rust code to gain access to default values of in-core extensions that have a Rust implementation, we need to centralize them alongside the core items declarations. This is the first and so far only one of the extensions that have gained Rust support, I don't think it's worth the churn to move the rest of the extension's configitems yet.
Mon, 13 Feb 2023 18:11:48 +0100 rust-config: add config getters that don't fall back to defaults
Raphaël Gomès <rgomes@octobus.net> [Mon, 13 Feb 2023 18:11:48 +0100] rev 50764
rust-config: add config getters that don't fall back to defaults This is useful in cases where we access config items that are more... lenient with their types than a fresh new system would allow. For now there is only a single use of this, but we might get more later.
Thu, 06 Jul 2023 14:32:07 +0200 rust-config: add support for default config items
Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jul 2023 14:32:07 +0200] rev 50763
rust-config: add support for default config items Now that configitems.toml exists, we can read from it the default values for all core config items. We will add the devel-warning for use of undeclared config items in a later patch when we're done adding the missing entries for `rhg`.
Mon, 23 Jan 2023 18:08:11 +0100 configitems: declare items in a TOML file
Raphaël Gomès <rgomes@octobus.net> [Mon, 23 Jan 2023 18:08:11 +0100] rev 50762
configitems: declare items in a TOML file Mercurial ships with Rust code that also needs to read from the config. Having a way of presenting `configitems` to both Python and Rust is needed to prevent duplication, drift, and have the appropriate devel warnings. Abstracting away from Python means choosing a config format. No single format is perfect, and I have yet to come across a developer that doesn't hate all of them in some way. Since we have a strict no-dependencies policy for Mercurial, we either need to use whatever comes with Python, vendor a library, or implement a custom format ourselves. Python stdlib means using JSON, which doesn't support comments and isn't great for humans, or `configparser` which is an obscure, untyped format that nobody uses and doesn't have a commonplace Rust parser. Implementing a custom format is error-prone, tedious and subject to the same issues as picking an existing format. Vendoring opens us to the vast array of common config formats. The ones being picked for most modern software are YAML and TOML. YAML is older and common in the Python community, but TOML is much simpler and less error-prone. I would much rather be responsible for the <1000 lines of `tomli`, on top of TOML being the choice of the Rust community, with robust crates for reading it. The structure of `configitems.toml` is explained inline.
Mon, 23 Jan 2023 17:11:42 +0100 thirdparty: vendor tomli
Raphaël Gomès <rgomes@octobus.net> [Mon, 23 Jan 2023 17:11:42 +0100] rev 50761
thirdparty: vendor tomli The next commit will introduce a .toml file to abstract configitems away from Python. Python 3.11 has a toml read-only library (`tomllib`), which gives us a way out of vendoring eventually. For now, we vendor the backport, specifically version 1.2.3 which is still compatible with Python 3.6.
Mon, 23 Jan 2023 18:52:05 +0100 configitems: add `documentation` field
Raphaël Gomès <rgomes@octobus.net> [Mon, 23 Jan 2023 18:52:05 +0100] rev 50760
configitems: add `documentation` field It may be useful to expose documentation information in the help in some form. This will be populated in a future changeset by using the current comments that are relevant for users.
Mon, 23 Jan 2023 17:21:14 +0100 configitems: use standard "dynamicdefault" approach in edge case
Raphaël Gomès <rgomes@octobus.net> [Mon, 23 Jan 2023 17:21:14 +0100] rev 50759
configitems: use standard "dynamicdefault" approach in edge case This makes for fewer edge cases, which will help a future patch.
Tue, 17 Jan 2023 14:53:18 +0100 configitems: fix typo in devel warning about extension overrides
Raphaël Gomès <rgomes@octobus.net> [Tue, 17 Jan 2023 14:53:18 +0100] rev 50758
configitems: fix typo in devel warning about extension overrides
Wed, 28 Jun 2023 14:23:13 +0200 extensions: imp module is removed in Python 3.12 - use importlib to load files stable
Mads Kiilerich <mads@kiilerich.com> [Wed, 28 Jun 2023 14:23:13 +0200] rev 50757
extensions: imp module is removed in Python 3.12 - use importlib to load files imp has been deprecated for a long time, and has finally been removed in Python 3.12 . imp was only used for loading extensions that has been specified with direct .py path or path to a package directory. The same use cases can be achieved quite simple with importlib, , possiby with small changes in corner cases with undefined behaviour, such as extensions without .py source. There might also be corner cases and undefined behaviour around use of sys.modules and reloading.
Tue, 27 Jun 2023 13:05:03 +0200 utils: imp module is removed in Python 3.12 - get is_frozen() from _imp stable
Mads Kiilerich <mads@kiilerich.com> [Tue, 27 Jun 2023 13:05:03 +0200] rev 50756
utils: imp module is removed in Python 3.12 - get is_frozen() from _imp imp has been deprecated for a long time, and has finally been removed in Python 3.12 . The successor importlib is using the same internal _imp module as imp, but doesn't expose it's is_frozen. Using the internal function directly seems like the cleanest solution. Another alternative to imp.is_frozen("__main__") is sys.modules['__main__'].__spec__.origin == 'frozen' but that seems even more internal and fragile.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip