Hi,
In some cases, file names are really too long, so I’m wondering :
In Anatomy, the default Publish Templates have product[name] in both Directory and File Name templates.
With only one of them, it would already ensure unicity of representations.
Do you think something could go wrong if we removed product[name] from the File Name templates ?
Would be absolutely fine! 
Especially working on Windows in some cases it may be nice to use templates that aren’t as descriptive and result in shorter file paths. Especially with deep nesting of assets you can easily get into relatively long filepaths which Windows traditionally hasn’t been very keen on when going over around 260 (or is it 255?) characters or so.
Windows does support it now - you can enable the longer path support; however many tools and applications still use older Windows API calls that do not support the longer filepaths. For example, a simple os.path.exists file path in Python will just straight up fail to detect the file with too long filepath. There are workarounds, by supplying the path in a different format - but that’d mean you’d need to do that everywhere in the codebase and applications to fully support it.
E.g. this may make it work:
def normalize_path(path: str) -> str:
if os.name == 'nt' and len(path) > 260:
if not path.startswith('\\\\?\\'):
path = '\\\\?\\' + os.path.abspath(path)
return path
But every path we ever handle in AYON would then need to be remapped using this to be supported in all path related functions in Python 
I’d still love to know if there’s just an easy way to support it in Python without needing to manipulate the paths we’re passing around so that it’d just easily work across all integrations and the full code base with a minor change. Especially over the last years renderers and other tools seem to render and consume paths over 255 characters fine and we may be at a point where just Python is the remainder making this hard for us.
Or we replace all os using with pathlib.Path which does support longer paths on Windows.
But you’ll still get into the issues where applications will fail to open files with too long paths, e.g. even default notepad on Windows fails to open a .txt file from within such a path.
In short, getting the paths to be shorter may be the only realistic way in production.
Thanks for your answer 
The Windows 260+ path character limit was one of the reasons, but the most short-term need was to allow artists to see the name of their textures 
In Blender, on Image Texture nodes, there seem to be a 64 characters limit, that cuts what is displayed in both locations : the node’s top line, and the node’s Image name field.
So, as output from Substance Painter and OIIO, this is too long for Blender :
STAR_textureSurfacingPBRStandardLongFastMain.Normal_v021_png1024.png
(so the png resolution is clamped when displayed)
Problem : I can remove the product[name] from the File Name template (thanks for this information), but I still need to use the variant (which in the case of Substance Painter is Normal or AlbedoTransparency, etc…) so that artists see it’s the right file.
But Anatomy does not allow to use variant, I get this error :
Anatomy template is unsolved. Missing keys: “variant”
So, I can remove product[name], but I cannot replace it by one of its parts (variant).
Unfortunately this is the case - because variant isn’t currently part of the stored context or alike. I actually think it’s not even entirely a required value in the system too. Anyway, potentially shortening other parts of the “filename” may suffice too? E.g. doesn’t it by default contain e.g. project name or whatever? You could remove that? etc.
But yours doesn’t seem to.
Anyway, textureSurfacingPBRStandardLongFastMain.Normal seems like a crazily long product name regardless 
Yes, I already removed the project name.
I used on purpose a too long variant, for the example.
But the rest is shorter than usual :
STAR is a very short asset name.Normal is a very short map identifier, compared to AlbedoTransparency and MetallicSmoothness.Here is a more sensible example, that also has 68 characters :
THERMOMETER_textureSurfacingMain.MetallicSmoothness_v021_png1024.png
My product[name] is {product[type]}{Task[name]}{Variant}
I need the {Task[name]} there, to avoid this dreaded error (if you have 2 tasks of the same type on the same asset) :
Version ‘2’ from instance ‘modelMain’ that you are trying to publish is lower or equal to an existing version in the database. Version in database: ‘14’. Please version up your workfile to a higher version number than: ‘14’.
Our artists don’t want to handle the unicity themselves, for example with variant (and the unicity problem only appears too late, when publish fails, which drives artists crazy).
This discussion reminds me with: Restriction of uniqueness of product names
Bottom line of that post (off the top of my head) is to depend on product name and variant (as a composite key) to differentiate products as currently, It’s expected to have unique product names per folder (regardless of the task).