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
The phylum command treats .csproj files differently when passed as arguments to the command line as opposed to when they are found by a directory search... Specifically, running phylum parse sample.csproj will detect the file as type msbuild, while running phylum parse with no files and letting the tool find it will detect the file as nugetlock.
(The specifics here will change after #1435 is merged, but this problem may extend to other formats, so I wanted to track it separately)
What's your suggested resolution here? Do you want to verify that all parsers match the behavior with and without he file explicitly specified, or do you want to change the code so this is always guaranteed to be consistent?
While changing things to ensure consistency might make sense, I'm not too surprised that these behave differently considering they approach the problem from opposite ends.
Do you want to verify that all parsers match the behavior with and without he file explicitly specified, or do you want to change the code so this is always guaranteed to be consistent?
I think either approach would be fine. I believe #1435 has fixed the issue for csproj files, but I'd still like to make sure this isn't happening with any other file types.
The
phylum
command treats.csproj
files differently when passed as arguments to the command line as opposed to when they are found by a directory search... Specifically, runningphylum parse sample.csproj
will detect the file as typemsbuild
, while runningphylum parse
with no files and letting the tool find it will detect the file asnugetlock
.(The specifics here will change after #1435 is merged, but this problem may extend to other formats, so I wanted to track it separately)
The text was updated successfully, but these errors were encountered: