base_url for many projects is painful

[doki_pen <doki_pen@…>]

Setting the base_url in hundreds of ini files, and changing them with a hostname change is painful. I've attached a patch for a parent_base_url trac.ini setting that can be used in a parent trac.ini.

[doki_pen <doki_pen@…>]

Add a parent_base_url setting.

[osimons]

It would be useful, and it was also briefly raised by me on #5064 a while back.

As I see it, there are two alternatives:

1. Like your patch introduce a new setting for 'parent'.
2. Or, introduce substitusion in the original base_url so that you can write base_url = http://myhost/trac/$folder for instance.

Regardless, many places in Trac and not least external plugins and scripts make reference to the base_url setting, so I expect a fair amount of breakage for any change in setting or calculation (like the story with #5064). I need other devs to chime in with their opinion before anything gets committed.

[doki_pen <doki_pen@…>]

I originally tried using the interpolation feature in ConfigParser to do something like this

# parent.trac.ini
[trac]
parent_base_url = http://myhost/trac

# trac.ini
[inherit]
file = parent.trac.ini

[trac]
base_url = %(parent_base_url)/myproject

But discovered that it doesn't work. The inheritance feature is implemented at a higher level then the interpolation feature. Perhaps this should work and the is what should be changed, but it seemed more difficult.

[dave@…]

Mightn't it be easier as environ?

[osimons]

#8288 has been closed as a duplicate - it also requests some form of substitution mechanism when parsing trac.ini.

I'm quite partial to a flexible system, and the idea proposed by ebray on that ticket of using ${section:option} replacement makes sense. That way an inherited trac.ini file can reuse or define whatever option it needs to be reused by children.

In addition, this mechanism could support a special ${environ:variable} lookup that reads environment settings instead of looking up configuration files.

We'll skip substitution on a substitution to avoid initiate loops, but otherwise this would be a simple and easy scheme to implement.

[boftx@…]

I just closed #8521 as a duplicate of this ticket. I agree with the approach taken by the patch above becuase I think there should be no need for editing the individual trac.ini files in each project. If I understand how the patch works, all I would need is a single entry for "parent_base_url" in the inherited trac.ini file and no further changes would be needed as "base_url" by default is empty.

I originally entered this as a request due to problems encountered with TicketMover. (see ​http://trac-hacks.org/ticket/5560 for that discussion)

Is there any reason why this patch would not work on 11.4?

[Remy Blank]

Simon, what's the currently-favored solution for this issue? Should we keep it for 0.12?

[Christian Boos]

The patch looks good.

It's an .ini setting that you have to enable explicitly after all, so we could flag it (experimental) and let the users validate it. If we get negative feedback, we could still fix it later… So +1 from me.

[Remy Blank]

Simon, I'll take care of this, if you don't mind.

[Remy Blank]

Unfortunately, the patch is incomplete. It correctly sets env.abs_href, but web/main.py accesses env.base_path directly, to set environ['trac.base_path'], which is then used to construct req.abs_href.

One possibility would be to make env.base_path a property, and to rename the Option to e.g. base_path_opt. Thoughts?

[Remy Blank]

Moving this out of 0.12 until the issues in comment:10 are addressed.

[Christian Boos]

[OT] would be useful to highlight the heading corresponding to the selected comment link. Here, if I click on comment:10, the comment:7 would be shown at the top of the page, for page height reason. While entirely logical, it was somewhat confusing and a dynamic highlight would have helped (same story for the wiki page section headings, btw).

[osimons]

#9586 closed as duplicate.

[anonymous]

I really like the ${section:option} version. It would make my life a lot easier. I can use that for the password_file and logo_file options.

I'm creating a tool to automate the deployment of tracs, and adding a small section with my tools name and some variables I can use in the rest of the config file would be awesome.

[Remy Blank]

Refocusing.

[anonymous]

Hi, how is the status of this ticket?

[strk@…]

I'm also looking for ways to reduce pain of setting base_url for multiple instances. Was an alternative found for Trac 1.0+ ?