Possibly minor bug in base folder hint

I am not sure if I misunderstood something, but I feel like in following screenshot, the path after “Using external tox base folder” shouldn’t contain comp at the end, right?

Please feel free to take a look at an example file - when you hover mouse over File parameter on base1, it shows this info.
little_bug.zip (4.6 KB)

I assumed this path should still be relative to the toe file location - I thought the concept of relative paths starts to apply for everything within the component, not to its parameters. (Please is this assumption correct?) Therefore it seems like it is pointing to a right file, but the explanation of base folder seems wrong to me. Also the info “Using external tox base folder” sounds wrong at this level - as it isn’t yet using the external tox as a base folder, right? At this level it should say “Using project base folder”…

Hmm, as I am starting to understand these new relative paths a bit more, I don’t feel like this is a bug anymore. It kinda started making more sense as I dived a little deeper into possible use cases… Its good the way it is, sorry. Marking this as solved :slight_smile:

Thanks for the question and the response. I had been looking into your example, but it re-ignited some internal debates/questions about the evaluation context for the relative paths which we’re still discussing.

However, in general I think you are correct in saying that the relative path behaviour applies within the component and the parameters on the “outside” of the component follow the rules of their parent rather than their own settings.

This is definitely true for the component’s ‘External Tox Path’ parameter to allow for proper nesting of relative paths, but I think it makes sense for custom file parameters on the component as well since in most cases people would use these to point to files outside of the component “package”.

That said, this doesn’t work well right now if you bind a file parameter on the outside of the component to a parameter inside the component. These currently get evaluated differently based on each context and this is something we’re looking into resolving.

Thanks for reply @robmc.

This is exactly what I realized later on - that the evaluation context plays important role in this. However this way you designed it somehow started to make sense to me… I feel like it makes sense that parameter being evaluated on the outside points to different location then parameter on the inside (even if there is bind between them). I imagine the bind is done just on plain “string level”.

I am not sure what are the most common use cases for other people, but right now I am thinking about some of my components that require config files. These have file parameter called Config (which is placed of the component itself). This file doesn’t really point “outside”, but rather to a config file located near a tox file. I know this relative path would be incorrectly evaluated on the “outside” of the component, but at the same time it is being correctly evaluated within it (which is what I was looking for in this use case). This is just one example that comes to my mind right now, but I am sure there are many others (also with files pointing somewhere outside like you said).

Nevertheless this makes me wonder what other approach to this “evaluation context problem” are you considering? Maybe some file-parameter-specific right click menu available on components - with possibility to choose between inside/outside evaluation context?

…Btw one thing I really like is the fact that relative paths work across clones. This is great design decision. :slight_smile:

Actually I have just realized the example with config files wasn’t ideal. :grin: While I was taking a closer look these configs, I have noticed this is a little more messy than what I have thought - sometimes they point to a default config relative to the tox file, but once the component gets integrated to some project/component, they point “outside” - to config relative to that project/component. Agh, bad example, sorry - even such simple example got more complicated than I thought :smiley:

Thanks for the discussion. I’ve made a couple of changes that we’re currently testing internally. The file parameters are now evaluated based on the top of the binding chain, which should give more consistent results.

This means that you can promote and bind a file parameter from inside a component to a custom parameter on the parent and evaluate it consistently using that parent’s behaviour.

I’ve also added a new ‘evalFile’ method for pars that will expand the path using the same relative path rules as we use internall. It returns a tdu.FileInfo object

I can get you a preview build when it’s available if you are interested in testing it as well.

This sounds good, thanks for info. 'evalFile’ method is great addition, this will make it much easier to work these relative paths in python.

In a scenario where I would like to use path relative to component’s tox file in a file parameter placed on component itself, I could still use something like this expression to do so: me.fileFolder + '/default_config.json', right? I guess this should work as it would essentially expand to full path, so no relative rules would apply to it.

Preview build sounds good, thanks.

Hi Rob,

while looking at new release notes, this sentence caught my attention:

Custom parameters now use the relative file path behavior of their own node. Only the External .tox path uses the parent’s path behavior.

Please does this mean that both parameters “inside” and on the “outside” of a component (excluding ‘External Tox Path’ parameter) follow the same relative file path logic? I am asking this just to make sure I understand it correctly - as this now seems like a contrary to logic previously described here:

Everything uses the relative path of the container/network they are in. So parameters on the ‘outside’ of a component, like it’s custom parameters, will base their path on their parents location. There are always counter examples, but this seemed like the most consistent behaviour based on our internal discussions.

You can always use the python expressions op.fileFolder to build a path to something inside the component if you need to.

Hope that makes sense. Let me know if you have any questions or run into any problems.

Aha, I see, I have misunderstood the release notes - I thought there was some change in this logic, but now I see it works the same way as before (which is good in my opinion). Thanks for explanation, I guess I just got confused.