# Galaxy-importer enforces undocumented length limitations on collection metadata **URL:** \ **Category:** Get Help\ **Tags:** galaxy-ng\ **Created:** [March 26, 2024, 11:46am UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573 "2024-03-26T11:46:56Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![evgeni](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/evgeni/32/2686_2.png) [@evgeni](https://forum.ansible.com/u/evgeni)\ **Post date:** [March 26, 2024, 11:46am UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573/1 "2024-03-26T11:46:56Z")
Ohai, galaxy-importer has code to enforce a schema upon the metadata in `galaxy.yml`: > I think this is problematic for two reasons: 1. those lengths are not documented as limits in [Collection Galaxy metadata structure — Ansible Community Documentation](https://docs.ansible.com/ansible/latest/dev_guide/collections_galaxy_meta.html) (which I consider the source of truth when developing things) 2. it’s super easy to hit those limits - even the example in the docs `Full Name (url) @nicks:irc/im.site#channel` is very close at 51 characters (vs 64), just imagine someone with a more complicated name than “Full Name” shows up 😉 Please reconsider limiting those fields, especially at such low lengths. ---
**Author:** ![evgeni](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/evgeni/32/2686_2.png) [@evgeni](https://forum.ansible.com/u/evgeni)\ **Post date:** [March 26, 2024, 11:47am UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573/2 "2024-03-26T11:47:27Z")
( Can’t not link to [Falsehoods Programmers Believe About Names | Kalzumeus Software](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/) and [Falsehoods Programmers Believe About Names - With Examples - Shine Solutions Group](https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/), sorry ) ---
**Author:** ![evgeni](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/evgeni/32/2686_2.png) [@evgeni](https://forum.ansible.com/u/evgeni)\ **Post date:** [March 26, 2024, 11:57am UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573/3 "2024-03-26T11:57:48Z")
BTW, [SPDX License List | Software Package Data Exchange (SPDX)](https://spdx.org/licenses/) does contain licences with identifiers longer than 32: - Mackerras-3-Clause-acknowledgment - BSD-3-Clause-No-Nuclear-License-2014 - X11-distribute-modifications-variant ---
**Author:** ![thedoubl3j](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/thedoubl3j/32/103_2.png) [@thedoubl3j](https://forum.ansible.com/u/thedoubl3j)\ **Post date:** [March 26, 2024, 3:50pm UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573/4 "2024-03-26T15:50:57Z")
I am not sure on the reasoning for this but IMO, this feels arbitrarily enforced especially since given the example, near one author could reach this limit. I understand the others or at least can see reasoning but personally, I am not sure this should be this low. I think their should be hard a cap (working in python has made realize, even if it might seem out of reach, always set a limit) but I do believe that it should be something that is near impossible to hit. @allhart @chynasan what do you all think about potentially changing this in one of the next releases? ---
**Author:** ![allhart](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/allhart/32/9400_2.png) [@allhart](https://forum.ansible.com/u/allhart)\ **Post date:** [March 26, 2024, 7:11pm UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573/5 "2024-03-26T19:11:09Z")
I don’t see any issues with raising the limit for at least author and license by a fair amount, but I wonder if there’s any historical reason for these values being so limited. I’m guessing namespace and collection name (aka NAME) shouldn’t change due to other dependencies in pulp/galaxy\_NG, and tag at 64 char seems like a reasonable amount IMO. Maybe raising LICENSE to 64/128 char and AUTHOR to 256 char would give enough leeway? We can always go higher if needed, as long as there’s not something in galaxy\_NG that will break if we raise it too much. Whatever we do or don’t do, I agree with @evgeni - this should be documented somewhere on docs.ansible. @tannerjc What do you think? ---
**Author:** ![kurokobo](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kurokobo/32/182_2.png) [@kurokobo](https://forum.ansible.com/u/kurokobo)\ **Post date:** [March 27, 2024, 12:30am UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573/6 "2024-03-27T00:30:41Z")
Those limitation were Introduced by this PR: - [Check collection metadata fields for maximum length by awcrosby · Pull Request #108 · ansible/galaxy-importer · GitHub](https://github.com/ansible/galaxy-importer/pull/108) There is a link to: - [Loading...](https://issues.redhat.com/browse/AAH-55) > For the authors field, currently the limit is noticed when there is a database error in AH, and this is displayed to the user: > `{'authors': {1: [ErrorDetail(string='Ensure this field has no more than 64 characters.', code='max_length')]}}` > [Loading...](https://issues.redhat.com/browse/AAH-55) Is this a still valid consideration that AH has 64 chars limit? ---
**Author:** ![kurokobo](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kurokobo/32/182_2.png) [@kurokobo](https://forum.ansible.com/u/kurokobo)\ **Post date:** [March 27, 2024, 12:36am UTC](https://forum.ansible.com/t/galaxy-importer-enforces-undocumented-length-limitations-on-collection-metadata/4573/7 "2024-03-27T00:36:03Z")
I see that `pulp_ansible` still has the limitations with `max_length` for several fields. So it seems that fixing galaxy-importer alone will not solve the problem. >