You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem
Upon doing further research on the changes in recipe search logic in 3.0 as compared to 2.7.2 and earlier, the new logic as described in the code comments does not produce the same results in certain circumstances. Here is the logic, as described in the comments:
# 1. Look for a path to a file first, return path to file
# 2. If not a path, look for it in recipe map, return path to file
# 3. If not in recipe map, search for it in the search directories, return path to file
# 4. If not in search directories, return none
# 5. If no path to file, error and fail
This essentially changes it so that search directories not in the map have lower priority than those that are. This is why #886 fails in the way I have documented there.
The logic that would provide the same results as AutoPkg 2:
Look for a path to a file first, return path to file
If not a path, search for it in the search directories, one by one:
If the directory is a GitHub repo, look for it in the recipe map, return path to file
If it is not, search the directory directly, return path to file
If not in search directories, return none
If no path to file, error and fail
I have no idea whether doing it this way would reduce or eliminate the speed gains of the map. But semantically, the two plans for search (v. 2 and v. 3) are not the same.
The alternative would be to split RECIPE_SEARCH_DIRS into two: directories that get mapped and directories that don't. That could be split on GitHub repo/locally-created directories, but doesn't necessarily have to be. One should be able to specify which get checked first if you are not going to default to the existing behaviour where ., /Library/Recipes, and ~/Library/Recipes (which I would not include in the map) get searched first.
Version (please complete the following information):
OS version: 12.7, 13.6, 14.0
AutoPkg Version: 3.0.0 RC2
The text was updated successfully, but these errors were encountered:
THIS IS ONLY INTENDED FOR AUTOPKG BETAS.
Describe the problem
Upon doing further research on the changes in recipe search logic in 3.0 as compared to 2.7.2 and earlier, the new logic as described in the code comments does not produce the same results in certain circumstances. Here is the logic, as described in the comments:
autopkg/Code/autopkg
Lines 288 to 294 in d72a5a5
This essentially changes it so that search directories not in the map have lower priority than those that are. This is why #886 fails in the way I have documented there.
The logic that would provide the same results as AutoPkg 2:
I have no idea whether doing it this way would reduce or eliminate the speed gains of the map. But semantically, the two plans for search (v. 2 and v. 3) are not the same.
The alternative would be to split
RECIPE_SEARCH_DIRS
into two: directories that get mapped and directories that don't. That could be split on GitHub repo/locally-created directories, but doesn't necessarily have to be. One should be able to specify which get checked first if you are not going to default to the existing behaviour where.
,/Library/Recipes
, and~/Library/Recipes
(which I would not include in the map) get searched first.Version (please complete the following information):
The text was updated successfully, but these errors were encountered: