The name fpm is used by another package manager

[certik]

It was just pointed out to me that fpm is used by another project: https://github.com/jordansissel/fpm. Unfortunately it is in a similar field (also a package manager).

Here are some options going forward (I'll update this list if there are more):

1. Rename our fpm
2. Keep the name fpm and ensure that people do not mistake the two projects (what's the best way?)

As to myself, I really like the name fpm to mean a Fortran Package Manager. So I vote for 2., if there is a way to do it.

[everythingfunctional]

I vote for 2 as well. I think the two are sufficiently different, but knowing it's out there we can be conscious to avoid confusion as much as possible.

On a side note, should we use that tool to create our Linux packages?

[milancurcic]

This is unfortunate, though not surprising.

As the originator of the name, I'm sorry. I should've done better research. :(

My preference is also for 2, because I like the name. However I see issues ahead of us, and it will only be more difficult to rename later. Issues are:

• Confusion
• Conflict (both CLI tools are called fpm)
• Bad look on us as the community, as we are a younger project

On a side note, should we use that tool to create our Linux packages?

Though it sounds like a good idea, now we're really screwed: "So fpm will package fpm for Linux. Wait, which fpm is this? Is it this fpm or the other fpm?". I'm confused already. :)

So I vote for 2., if there is a way to do it.

Let's discuss how we could do it. This would probably mean putting a large disclaimer at the top of our README, saying "This fpm is not the other fpm", or similar. What else?

@jordansissel Do you have any advice for us?

[jordansissel]

I ran into this myself shorty after releasing (my) fpm! I learned there’s a tool PHP-FPM That many folks call FPM. Naming is hard. It’s hard to know if conflicting names will cause difficulties. I’ve run into weirdness myself with things on Debian like “docker” package not being the container runtime tool. I think my advice is this: if you feel fpm is the right name for your tool, then please keep the name. Computers and humans will likely figure this out on their own with their own workarounds that aren’t too harmful. Examples abound, like you can’t really search for “go” so while the language is Go you gotta search golang. It’s a weird workaround but it works most of the time. Is this a bad look? I don’t think so! +1 for a clarification at the top of the README. I’d be happy to include a similar clarification in my fpm readme and docs. Something short and direct that describes the project (FORTRAN for this one) and offers disambiguation links to help any wayward travelers. I agree with concern about command line name conflicts, but it’s unclear what negative impact this will have. Again here we have examples like downstream OS calling “pip” executable “python3-pip” or similar naming solutions. That said, it’s probably fine to keep the cli name the same? As for search/discovery, “fpm” plus any context should help search engines find the right place for users. Thoughts? Having the project and cli name be the same has low risk in my opinion.

…

On Thu, Jun 4, 2020 at 2:24 PM Milan Curcic ***@***.***> wrote: This is unfortunate, though not surprising. As the originator of the name <fortran-lang/stdlib#44 (comment)>, I'm sorry. I should've done better research. :( My preference is also for 2, because I like the name. However I see issues ahead of us, and it will only be more difficult to rename later. Issues are: - Confusion - Conflict (both CLI tools are called fpm) - Bad look on us as the community, as we are a younger project On a side note, should we use that tool to create our Linux packages? Though it sounds like a good idea, now we're really screwed: "So fpm will package fpm for Linux. Wait, which fpm is this? Is it this fpm or the other fpm?". I'm confused already. :) So I vote for 2., if there is a way to do it. Let's discuss how we could do it. This would probably mean putting a large disclaimer at the top of our README, saying "This fpm is not the other fpm", or similar. What else? @jordansissel <https://github.com/jordansissel> Do you have any advice for us? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2WIFDF5BRL244MHV4LRVAGKDANCNFSM4NS7GCRA> .

[milancurcic]

Jordan, thanks a lot. With your encouragement I now feel more comfortable keeping the name, and making it clear in the README to avoid confusion.

So if @certik and @everythingfunctional agree, we'll add the clarification and link to the top of the README.

[certik]

@jordansissel thank you for your nice comment. Since you are ok with us keeping the name, I am too. @milancurcic yes, let's send a PR with a clarification at the top of our README and docs. That should make it clear to users.

I agree with Jordan that there are ways around it. For example Debian has the alternatives system, so users will be able to choose what they want to run as fpm.

[everythingfunctional]

I am in agreement. Good call just reaching out and asking, and thank you @jordansissel for your understanding and encouragement.

[certik]

Here is an example how Spack disambiguates the name:

https://spack.readthedocs.io/en/latest/

They write:

These are docs for the Spack package manager. For sphere packing, see pyspack.

[nshaffer]

The fpm help text gave me an idea for an alternate name.

wwf - working with Fortran

It seems like the naming crises has passed, but I'm just too tickled by the idea of scientists and engineers co-opting "WWF" to mean their package manager.