Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Odd format detection for csproj files #1436

Open
kylewillmon opened this issue Jun 3, 2024 · 2 comments
Open

Odd format detection for csproj files #1436

kylewillmon opened this issue Jun 3, 2024 · 2 comments
Labels
bug Something isn't working low priority Should be handled as time permits

Comments

@kylewillmon
Copy link
Contributor

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)

> phylum status
Project: null
Group: null
Project Root: null
Dependency Files:
 - path: ./sample.csproj
   type: nugetlock
> phylum analyze -p foo sample.csproj
✅ Successfully parsed dependency file "sample.csproj" as type "msbuild"
@kylewillmon kylewillmon added bug Something isn't working needs triage Needs to be reviewed or assigned labels Jun 3, 2024
@cd-work
Copy link
Contributor

cd-work commented Jun 4, 2024

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.

@kylewillmon kylewillmon added low priority Should be handled as time permits and removed needs triage Needs to be reviewed or assigned labels Jun 4, 2024
@kylewillmon
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working low priority Should be handled as time permits
Projects
None yet
Development

No branches or pull requests

2 participants