[25.1] Do not resolve symlinks at tool load time

[guerler]

Galaxy is now constructing the tool config path with os.path.realpath at load time, which freezes ${__tool_directory__} to the resolved physical directory and breaks for admins who deploy tool updates via atomic symlink swaps. They needed to reboot Galaxy otherwise the symlink target change had no effect. If pulsar needs canonical paths, we should resolve it on the pulsar side, not in the Galaxy tool layer.

Restores prior behavior by reverting: 20b691b7cd#diff-17974c8048767aa536063088ba97dbc9c4475e7589002c3b2335f9e8490fc920L1019

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[mvdbeek]

Why do you think i would agree to this ? Impossible to resolve for pulsar. If you want to deploy that way set up a monitor directory or trigger manual toolbox reload.

[mvdbeek]

This also 100% breaks reproducibility so I would let the deployer know that.

[guerler]

I agree with the reproducibility concern, that was my first reaction too, why not use the toolshed and/or just version properly. But this was existing accepted behavior for over a decade, and some admins relied on it. The realpath change broke it without a deprecation path. Previously, updating the symlink target plus toolbox reload was sufficient. After this change, the old physical target stays pinned until Galaxy restart. Toolbox reload sounds good, what would be the easiest way to trigger that for an admin?

[mvdbeek]

i guess?

Or use <tool_dir dir="/path/to/dir"/> which seems like a better thing than symlink swaps ?

We're not gonna announce deprecation of a thing we never supported ;)

[bwlang]

I would think you would agree to it to maintain consistent behavior over time :)

Was that change to realpath fixing a bug that caused problems for pulsar?

We'll explore that dir path or or maybe just hit that api during our deploy to see if that helps.