RezPlugin package_repository breaks when @ in repo path

[aprayez]

The issues is that when a package repo path looks like 'foo@/bah', it is interpreted as a repo where package payloads are stored on filepath /bah, and the plugin type is 'foo'.

I think it would suffice to only interpret the prefix as a plugin type if it matches a restrictive regex (alphanumeric/underscore).

https://groups.google.com/forum/#!topic/rez-config/Z7NdidsJNUY

[ruzette]

+1 for this bug fix as well. Thanks!

[nerdvegas]

This is coming soon, next on my list after a tasty feature that's hopefully getting released today.

[Ahuge]

Would love to see this hit too!

Thanks

[instinct-vfx]

As mentioned in the other issue it is possible to work around this by explicitly defining the path with a type e.g. filesystem@path/with/@/symbol. Are there cases where this does not work either or is this about a more convenient way to handle this?

maybe specifying the type like a transport protocol would be an alternative in that case?

[nerdvegas]

Thanks for reminding me about this one.

I think it'd be acceptable to interpret the string before @ only if it matches a repo plugin typename; otherwise it's taken as a literal path.

Transport protocol syntax would've been nice, but I don't want to break compatibility, nor support both syntaxes at once.

[halil3d]

Bit of a gotcha this one. We just encountered this when running rez builds via Jenkins on nodes running more than one build at a time, as the default behaviour is to suffix a path with @{job_number}. Didn't even know specifying the repository type was a thing! The more you know..

[marco-ff]

Hello, I've hit this bug recently. I wanted to run rez on an appliance that was configured for domain users. The HOME path would look like this: /home/[email protected]/

I've noticed this first while we were running .67 and I solved it by simply forcing all commands to be run with the --nl flag. That skipped the local folder check and solved the issue for me.

Then we bumped up to .112 and my --nl workaround stopped working. I am now re-setting HOME on the fly to a symlinked folder, i.e. /home/user@domain/ >>> /home/user/ and that works ok for now. It feels a bit messy but workable.

I'd be pretty happy to simply have --nl workaround working again since those machines will never have local packages.

Just realised... Couldn't I have a host filter in the rez config and remove "~/packages" for the affected clients?