Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot use config_opts[f"{config_opts.package_manager}.conf"] #1357

Open
hroncok opened this issue Apr 11, 2024 · 10 comments
Open

Cannot use config_opts[f"{config_opts.package_manager}.conf"] #1357

hroncok opened this issue Apr 11, 2024 · 10 comments

Comments

@hroncok
Copy link
Contributor

hroncok commented Apr 11, 2024

Short description of the problem

As a result of #1332 I can no longer use:

config_opts[f"{config_opts.package_manager}.conf"] += """
# whatever
"""

In configs that include Fedora branched.

I get:

ERROR: Config error: /tmp/fedora-39-x86_64-ci.cfg: '{% if releasever|int >= 40 %}dnf5{% else %}dnf{% endif %}.conf'

Output of rpm -q mock

mock-5.5-1.fc39.noarch
mock-core-configs-40.3-1.fc39.noarch
python3-templated-dictionary-1.4-1.fc39.noarch

Steps to reproduce issue

Full config (in /tmp/fedora-39-x86_64-ci.cfg):

include('fedora-39-x86_64.cfg')

config_opts[f"{config_opts.package_manager}.conf"] += """
# whatever
"""

command line:

$ mock -r /tmp/fedora-39-x86_64-ci.cfg --debug-config
ERROR: Config error: /tmp/fedora-39-x86_64-ci.cfg: '{% if releasever|int >= 40 %}dnf5{% else %}dnf{% endif %}.conf'
@hroncok
Copy link
Contributor Author

hroncok commented Apr 11, 2024

As a workaround, I can use config_opts["dnf.conf"] which seems to work both with dnf and dnf5.

@xsuchy
Copy link
Member

xsuchy commented Apr 11, 2024

  1. config_opts.package_manager does not exist. config_opts is a dictionary.

  2. You can use this:

include('fedora-39-x86_64.cfg')

config_opts['__jinja_expand']=True
config_opts[f"{config_opts['package_manager']}.conf"] += """                                                                                                                                 
# whatever
"""
config_opts['__jinja_expand']=False

This is because of https://github.com/xsuchy/templated-dictionary?tab=readme-ov-file#enabling-expansion which has other reason that is stored somewhere in git-log. I can dig it up if you are really curious.

This is normally not needed for values, but required for keys. I should probably document it.

@hroncok
Copy link
Contributor Author

hroncok commented Apr 11, 2024

config_opts.package_manager somehow exists. I don't know how, but it does.

@hroncok
Copy link
Contributor Author

hroncok commented Apr 11, 2024

>>> from templated_dictionary import TemplatedDictionary
>>> td = TemplatedDictionary()
>>> td['package_manager'] = 'dnf'
>>> td.package_manager
'dnf'

@hroncok
Copy link
Contributor Author

hroncok commented Apr 11, 2024

TemplatedDictionary stores the value:key pairs in self.__dict__, making them accessible as attributes.

@hroncok
Copy link
Contributor Author

hroncok commented Apr 11, 2024

As a side issue I've opened xsuchy/templated-dictionary#4

@praiskup
Copy link
Member

@xsuchy wrote:

You can use this:

include('fedora-39-x86_64.cfg')

config_opts['__jinja_expand']=True
config_opts[f"{config_opts['package_manager']}.conf"] += """

Actually you can not, jinja is only supported in values, not in keys.

@praiskup
Copy link
Member

Actually you can not, jinja is only supported in values, not in keys.

Wrong -> that's a f-string, not jinja. Sorry, you can use that. But ... it is unnecessary, you can simply use dnf.conf instead of abstracting the package_manager out. dnf.conf and yum.conf is completely equivalent key (these are aliased to each other).

@hroncok
Copy link
Contributor Author

hroncok commented Apr 11, 2024

(This issue is not blocking me in any way. But it is a regression nevertheless. If you decide to wontfix it, I'm OK with that.)

@praiskup
Copy link
Member

I'm careful to call this a regression because a) Jinja in the
TemplatedDictionary keys never worked, and yet b) it is expected to use Jinja in
TemplatedDictionary values. So your change in #1332 was fine from this
perspective.

So such a problem happens when we use config_opts values for specifying
config_opts keys. This limiting factor was always there - and nothing has
changed or regressed for several Mock releases.

This admittedly was/is a serious problem, though. The copr mock-config used to
provide the unfortunate output
(config_opts[f"{config_opts['package_manager']}.conf"] = ... ), and if cached
by our user - the problem still keeps appearing somewhere in the wild.

I decided to WONTFIX this particular instance of Jinja-in-key problem before
:-) because I thought there was no better way to achieve the result. But now I
think there is, namely using the logic from #1347.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants