#In PEP 825 thread, there was a request

1 messages · Page 1 of 1 (latest)

dawn crown
quick hawk
#

I personally don't know that we need to put a limit in the PEP. Project names and Versions already let you create unbounded length filenames, so adding yet another way to do that doesn't seem like it actively hurts anything to me.

I think it's fair to point out that variants as written require a longer file name (and that's true even if you limit the tag length to 1), and that's a trade off we're making. I don't know that we need to solve the 255 filename limit since it's not a problem created by this PEP.

#

IOW we could make variants not require longer filenames by trying to piggyback ontop of the platform tag instead of a separate field-- there's good reasons not to do that, but it's just a trade off we're making.

last otter
#

(Ah, I see now @dawn crown beat me to it 😉 )

#

@quick hawk I think you're right that it's not this PEP's problem, but longer it goes unaddressed, the longer it will go unaddressed, and there's an opprtunity to surface and solve now instead of kicking the can down the road

quick hawk
#

My bigger point is that I don't think there's a limit the PEP could pick that's actually safe? Because what's safe depends on project name, version, all the platform/python/release tags... and the path that the file is being installed into.

Right now the PEP arbitrarily picks 16, but 16 isn't a safe number, neither is 32, neither is 0. So putting a limit on it doesn't really do much to solve the problem. I guess we could concretely say that 256 is always unsafe 😉 but only for windows!

#

eliminating the path aspect of it for a second, 16 could be safe, until I make a project name that's one letter too long and now only 15 is safe.

fervent rock
#

So, any specific suggestion? Leave as-is, increase, replace with a generic filename length warning?

fervent rock
#

@last otter, @quick hawk, would you be opposed to removing the limitation under the assumption that the PEP specifies installer behavior and installers should be liberal in what they accept?

last otter
#

I'm not an authority on the text of the PEP, or what should or shouldn't be included, I'm only pointing out that we keep having discussions about standards that consume a limited resource without acknowledging it. We already have packages that consume resources and are not usable, and I hope that we can find ways to prevent that going forward.

quick hawk
#

I think removing the limitation is fine. I’d maybe mark in the rationale that this will make the length problem worse, but any limit will make it worse, and it’s up to projects to ensure their file names aren’t too long.

#

If we wanted to limit the length of file names PyPI could just do that on its own

#

But afaik it only affects windows, so idk if it would make sense to have a global limit or a windows only limit? Idk

last otter
quick hawk
#

Hmm Wikipedia says it’s 1023 for zfs, but either way. I don’t think a limit on this field does anything to fix the problem. Any number we pick is entirely arbitrary because it feels like maybe it’s fine. Is 16 safe? It’s impossible to know without more information

dawn crown
#

in the warehouse from the previous thread, we're usually way below 255 for the actual filename

#

there's more of a question what filename length is ergonomic for me

quick hawk
#

in general, I'm a fan of limits like that being at the discretion of the tools, with PyPI being a pretty big hammer we can wield. If the spec allows arbitrary length but PyPI puts reasonable limits on it, we get most of the same benefit but all the other tools know they have to be able to handle arbitrary lengths, so if we want to relax the length in the future it's easier to do.

last otter
last otter
quick hawk
#

👍

#

Could also just be an issue on warehouse probably

#

Or whatever

last otter