# Environment marker for free-threading **URL:** \ **Category:** Packaging\ **Tags:** free-threading\ **Created:** [August 5, 2024, 6:42am UTC](https://discuss.python.org/t/environment-marker-for-free-threading/60007 "2024-08-05T06:42:59Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\ **Post date:** [January 31, 2025, 1:51pm UTC](https://discuss.python.org/t/environment-marker-for-free-threading/60007/8 "2025-01-31T13:51:27Z")
> [@rgommers](#): > > For the suggested extension mechanism, did anyone already think in more detail about this and have a suggested implementation direction (static vs. semi-static vs. completely dynamic, syntax, …)? I think it would make sense to essentially expand `sys.abiflags` into a list with proper feature/variant names, which could live in `sys` or `sysconfig`. The marker, then, would be something like `'free-threading' in sysconfig.abi_features`. Technically, we could do `'t' in sys.abiflags`, but we could really use proper standardized names for ABI flags — no more is it “free-threading” or “nogil”? — so we might as well take the opportunity to add this API. Backwards compatibility wouldn’t be much of an issue, on older versions, we just translate `sys.abiflags` to the names chosen in the new API. > [@rgommers](#): > > Do (1), plus add an extension mechanism. I think that’s a bundle of complexity on its own, I wonder if it wouldn’t be better off as a separate PEP. That said, I really like the idea. We implemented something similar in Conda. Here, for example, the CUDA version is implemented as a plugin. In this case, a first-party one, but 3rd parties could do the same. > --- _[View the full topic](https://discuss.python.org/t/environment-marker-for-free-threading/60007)._