Feature Request: In versions 3.0+, make search for recipes case-insensitive again (or selectable by user?)

[workflowsguy]

THIS IS ONLY INTENDED FOR AUTOPKG BETAS.

Describe the problem
In AutoPkr 3.0RC2, searching for recipe names is now case-sensitive, whereas it was case-insensitive in 2.x.
I initially tripped over this when I was "reusing" autopkg commands from the shell's history that had the recipe names in lower case, which after running for quite some time, caused the search to fail (but gave a suggestion for the correct spelling, which I overlooked...).

Expected behavior
As there are pros and cons for both keeping and changing the behaviour, @nmcspadden has suggested opening an enhancement request for a discussion about this.

I don't know what the default behaviour could be, but maybe there could be a preference setting that can be set by the user and overriden through a command line argument?

Version (please complete the following information):

• OS version: -
• AutoPkg Version: 3.0+

[gregneagle]

I think it's certainly reasonable for a search intended to be consumed by humans to be case-insensitive. If I search for "GoogleChrome" I probably want to see "googlechrome" as a match.
It's less clear how this behavior should be for, say, an autopkg run of a list of recipes. If that list contains

GoogleChrome.munki

But there are "GoogleChrome.munki.recipe" and "googlechrome.munki.recipe" recipes in the search paths, and "googlechrome.munki.recipe" is actually higher in the search path, should autopkg run that? What is the current behavior? Is this behavior what a human might expect?

[gregneagle]

Some of the ambiguity and possibly unexpected behavior here (and elsewhere!) might possibly be addressed by having autopkg run by default only find and run recipes from the RecipeOverrides directory. It would then require a special flag to have it search outside the overrides...

[nmcspadden]

Another question is, should we _allow_ override names that only differ by case? i.e. if AutoPkg first encounters "GoogleChrome.munki", and then later finds "googlechrome.munki", should it just warn the operator and skip over it, and pretend it doesn't exist? Or should it treat them as separate independent entities? Or should it ignore case and whichever is read last "wins"? My recommendation is the first option. I think AutoPkg should warn the author if you have an existing recipe or override name that differs only by case, and skip it after the first one.

…

On Thu, Dec 14, 2023 at 11:56 AM Greg Neagle ***@***.***> wrote: Some of the ambiguity and possibly unexpected behavior here (and elsewhere!) might possibly be addressed by having autopkg run by default *only* find and run recipes from the RecipeOverrides directory. It would then require a special flag to have it search outside the overrides... — Reply to this email directly, view it on GitHub <#919 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJFTX2ATMBRFYY6U43VTFTYJMVSHAVCNFSM6AAAAABAVDMJW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJWGIYDKOBXHA> . You are receiving this because you were assigned.Message ID: ***@***.***>

-- -- Nick McSpadden ***@***.***

[gregneagle]

With overrides this sort of naming conflict is far less likely, since by default all overrides are stored in a single directory.