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

Analyzer does not allow to have multiple independent projects with the same type / name / version #8498

Open
sschuberth opened this issue Apr 8, 2024 · 6 comments
Labels
analyzer About the analyzer tool enhancement Issues that are considered to be enhancements

Comments

@sschuberth
Copy link
Member

sschuberth commented Apr 8, 2024

See

// TODO: It might be, e.g. in the case of PIP "requirements.txt" projects, that different projects with
// the same ID exist. We need to decide how to handle that case.
val existingProject = projects.find { it.id == projectAnalyzerResult.project.id }

The same occurs when analyzing e.g. https://github.com/aws/glide-for-redis.git as it contains multiple (independent) Cargo.toml files wit the same content, like

$ head -5 go/Cargo.toml
[package]
name = "glide-rs"
version = "0.1.0"
edition = "2021"
license = "Apache-2.0"
$ head -5 java/Cargo.toml
[package]
name = "glide-rs"
version = "0.1.0"
edition = "2021"
license = "Apache-2.0"
@sschuberth sschuberth added enhancement Issues that are considered to be enhancements analyzer About the analyzer tool labels Apr 8, 2024
@sschuberth
Copy link
Member Author

@oss-review-toolkit/core-devs, how about if we simply add parent directory names as suffixes to the project name until the is unique?

@mnonnenmacher mnonnenmacher changed the title Analyzer does not allow to have multiple independetent projects with the same type / name / version Analyzer does not allow to have multiple independent projects with the same type / name / version Apr 8, 2024
@mnonnenmacher
Copy link
Member

A couple of questions:

Do you propose this as a general solution or specific to Cargo?

Why add the directory names as suffixes and not prefixes? That seems unintuitive. I would rather prefix them and always take the full path, as it could otherwise be confusing. So for the example above use the names java/glide-rs and csharp/lib/glide-rs.

Should this always happen or only if there are conflicting names?

@sschuberth
Copy link
Member Author

Do you propose this as a general solution or specific to Cargo?

As a general solution, see also the PIP case mentioned in the quoted TODO.

Why add the directory names as suffixes and not prefixes?

Because at the Cargo example, I find glide-rs-go / glide-rs-java to read nicer than go-glide-rs / java-glide-rs. (I probably should have said that I envisioned dashes instead of slashes as separators.)

Should this always happen or only if there are conflicting names?

Probably yes, as otherwise names could get unnecessary complicated.

@mnonnenmacher
Copy link
Member

I kind of like this approach, however I'm not sure about the details. For example, this approach could be difficult for package managers that support project dependencies (e.g. Maven), because those references might break if we rename projects.
Could you maybe collect some more examples to show how the naming algorithm would work for repositories that are affected by this issue? That would be good input to further refine the idea.

@heliocastro
Copy link
Contributor

Some insights here, are we aiming to a common global identification ?
Or if this is too much, maybe instead of dash could go to something like gradle representations:

glide-for-redis.go.glide-rs:0.1.0

Is this a little more logic considering that we have a better tracking from exact folder

@fviernau
Copy link
Member

fviernau commented Apr 9, 2024

I kind of like this approach, however I'm not sure about the details. For example, this approach could be difficult for package managers that support project dependencies (e.g. Maven), because those references might break if we rename projects.

IIRC in GoMod it could be analog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer About the analyzer tool enhancement Issues that are considered to be enhancements
Projects
None yet
Development

No branches or pull requests

4 participants