Allow feature names to start with a digit

@vkarak

[2026-09-08T16:05:03.799945] debug: reframe: Loading user configuration
[2026-09-08T16:05:03.800691] debug: reframe: Loading the builtin configuration
[2026-09-08T16:05:03.800969] debug: reframe: Loading configuration file: '/gpfs/home5/satishk/projects/eessi_reframe/settings_example.py'
[2026-09-08T16:05:03.823138] debug: reframe: '16_nodes' does not match '^[a-zA-Z_](?:[a-zA-Z0-9_-])*$'

Failed validating 'pattern' in schema['properties']['systems']['items']['properties']['partitions']['items']['properties']['features']['items']:
    {'type': 'string', 'pattern': '^[a-zA-Z_](?:[a-zA-Z0-9_-])*$'}

On instance['systems'][0]['partitions'][3]['features'][13]:
    '16_nodes'
[2026-09-08T16:05:03.823379] error: reframe: �[31mERROR: failed to load configuration: could not validate configuration files: `<builtin>`, `/gpfs/home5/satishk/projects/eessi_reframe/settings_example.py`: '16_nodes' does not match '^[a-zA-Z_](?:[a-zA-Z0-9_-])*$'�[0m
[2026-09-08T16:05:03.823557] info: reframe: Log file(s) saved in '/tmp/rfm-dzi295w_.log'

In the EESSI test-suite we use features where the number is used first and then the string for scales which are used as features for partitions within the configuration files.
@vkarak Can you relax this regex condition back to alphanumeric from just alpha? This started happening since we started to use ReFrame 4.10.2/4.10.3

Related issue #3645 , is it possible to release a patch or a minor version to fix this?

This is not a regression, but rather enforcing what the documentation states about partition/environment features:

The values of this list must be alphanumeric strings starting with a non-digit character and may also contain a -.

This pattern was enforced correctly since 4.10.1 by #3685.

However, I must admit that there is an inconsistency as the valid_systems mini-language allows for both leading zeros and .:

reframe/reframe/core/pipeline.py

Line 88 in 00ffd41

_F = rf'([+-]{_N})' # feature

I will rephrase this issue as feature request, as it is not a bug. I'm working on a PR that will address both #3645 and resolve the inconsistency reported here.

Related issue #3645 , is it possible to release a patch or a minor version to fix this?

It is going to be addressed in 4.11, but if you would like an earlier deployment, we could tag a dev release once it is merged.

@satishskamath

@satishskamath Can you try #3725 ?

@casparvl

This is not a regression, but rather enforcing what the documentation states about partition/environment features:

The values of this list must be alphanumeric strings starting with a non-digit character and may also contain a -.

This pattern was enforced correctly since 4.10.1 by #3685.

I respectfully disagree here...

I think this change should be treated as a bug/regression, exactly because it was fine to have values that start with digits for so long. In my view, the documentation was wrong here, and fixing that (and going back to allowing values with leading digits) would be sensible approach. That's just my view of course, this isn't my project. ;-)

Is there a specific reason why values with leading digits are problematic?

Not allowing values that start with a digit is problematic for the EESSI test suite, because it effectively makes the scale tags we have (see https://www.eessi.io/docs/test-suite/usage/#scale-tags) invalid all of a sudden. We could rename those of course, but that's quite annoying to anyone who's using the EESSI test suite, as they'll need to adjust accordingly...

The easier approach for us would be to detect which ReFrame version is used, and print a warning (or flat out refuse) if a ReFrame version that doesn't accept our scale tags as being valid (not sure if that's possible easily though).

cc @casparvl, @laraPPr, @smoors

I think this change should be treated as a bug/regression, exactly because it was fine to have values that start with digits for so long. In my view, the documentation was wrong here, and fixing that (and going back to allowing values with leading digits) would be sensible approach. That's just my view of course, this isn't my project. ;-)

I understand your view and it makes sense from the user's point of view. But I believe the docs expressed the original intent here (see the rationale below).

Is there a specific reason why values with leading digits are problematic?

Historically, the reason is that we wanted to be conservative with all the names that could appear in paths (system/partition/environment names). So originally we had two types of patterns: strict POSIX names and a relaxed version allowing hyphens. The problem was that these patterns were not anchored, so they matched anywhere in the string, effectively defying the original intent up until 4.10.1. I also just discovered a bug that since 3.11 all env_vars names in the configuration could allow hyphens (and before the strict enforcement, practically anything), leading to invalid export statements in the generated job scripts. Technically, this could have been used as a "feature" too.

When the features were introduced, we didn't want to introduce yet another pattern, so we reused the alphanum_ext_string. Technically, digits and other symbols could be part of the features, but historically, this hasn't been the intent.

This is what #3725 addresses in --I believe-- the correct way. Relaxes intentionally the syntax for system/partitions/environment/features and fixes the consistency between the features and the validation mini-language of valid_systems etc.

Not allowing values that start with a digit is problematic for the EESSI test suite, because it effectively makes the scale tags we have (see https://www.eessi.io/docs/test-suite/usage/#scale-tags) invalid all of a sudden. We could rename those of course, but that's quite annoying to anyone who's using the EESSI test suite, as they'll need to adjust accordingly...

You don't have to, because 4.11 will introduce these properly (#3725). Also how the tags in the docs you pointed above (which can be anything even now) are associated with the features that this PR mentions?

@vkarak

@vkarak Thanks for clarifying

Not allowing values that start with a digit is problematic for the EESSI test suite, because it effectively makes the scale tags we have (see https://www.eessi.io/docs/test-suite/usage/#scale-tags) invalid all of a sudden. We could rename those of course, but that's quite annoying to anyone who's using the EESSI test suite, as they'll need to adjust accordingly...

You don't have to, because 4.11 will introduce these properly (#3725). Also how the tags in the docs you pointed above (which can be anything even now) are associated with the features that this PR mentions?

OK, that's helpful. We still may need to refuse particular ReFrame versions though, to avoid people hitting the problem originally reported.

Note that the original error was exactly for one of these scaling tags, 16_nodes.
I'm not very familiar with the relation between these tags and features in ReFrame though, maybe @satishskamath (or someone else) can pitch in here...

@boegel

@boegel and @vkarak
Thank you for the clarification and discussion.

You don't have to, because 4.11 will introduce these properly (#3725). Also how the tags in the docs you pointed above (which can be anything even now) are associated with the features that this PR mentions?

We essentially use these scaling tags as features for partitions in the config files. This allows the sites to set the scales that are valid for them, the way their systems are configured. They can ban certain scales which are not useful or valid within their systems.

I agree with @boegel here that this was allowed until now, even though the documentation might have differed. Changing tag names also means that we may have to modify, certain other scripts within the EESSI project where these tests are regularly used.

Changing tag names also means that we may have to modify, certain other scripts within the EESSI project where these tests are regularly used.

Yes, but 4.11 addresses this properly in #3725. So, essentially, you are asking for a patch release to revert the enforcement?

@boegel

OK, that's helpful. We still may need to refuse particular ReFrame versions though, to avoid people hitting the problem originally reported.

@boegel This is also the case now. You have to refuse 4.10.1 to 4.10.3. 🤔

OK, that's helpful. We still may need to refuse particular ReFrame versions though, to avoid people hitting the problem originally reported.

@boegel This is also the case now. You have to refuse 4.10.1 to 4.10.3. 🤔

I agree. So I'm not really asking for a patch release, unless that can be done way faster than getting 4.11 out

I agree. So I'm not really asking for a patch release, unless that can be done way faster than getting 4.11 out

We can do a dev release tag once this is merged, if you don't mind using dev releases.

@boegel

We can do a dev release tag once this is merged, if you don't mind using dev releases.

@boegel The dev releases are just tags in the github repo, which you can install with using the git path, e.g., git+https://github.com/reframe-hpc/reframe.git@v4.10.2. They are not published as packages in PyPI. Hope that's fine for you.

We can do a dev release tag once this is merged, if you don't mind using dev releases.

@boegel The dev releases are just tags in the github repo, which you can install with using the git path, e.g., git+https://github.com/reframe-hpc/reframe.git@v4.10.2. They are not published as packages in PyPI. Hope that's fine for you.

That wouldn't really help us, we prefer using "proper" releases (and we don't control which ReFrame version others use anyway)

@boegel

@boegel and @vkarak see #3725 (comment)
So #3725 does solve the problem.

Navigation Menu

Repository navigation

Allow feature names to start with a digit #3723

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow feature names to start with a digit #3723

Description

Activity

satishskamath commented on Sep 8, 2026

vkarak commented on Sep 9, 2026

vkarak commented on Sep 9, 2026

vkarak commented on Sep 9, 2026

vkarak commented on Sep 9, 2026

vkarak commented on Sep 9, 2026

boegel commented on Sep 10, 2026

vkarak commented on Sep 10, 2026

boegel commented on Sep 10, 2026

satishskamath commented on Sep 10, 2026

vkarak commented on Sep 10, 2026

vkarak commented on Sep 10, 2026

boegel commented on Sep 10, 2026

vkarak commented on Sep 10, 2026

vkarak commented on Sep 10, 2026

boegel commented on Sep 10, 2026

satishskamath commented on Sep 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions