File collision with Ruby dotenv on /usr/bin/dotenv

[hartwork]

Hi!

It came to my attention that both Ruby dotenv and Python dotenv want to install/own file /usr/bin/dotenv. To a Linux distribution that wants (or needs) to package both of these, that's a problem because we cannot install both packages at the same time then which affects all reverse dependencies. Any thoughts?

Thanks and best, Sebastian

[bbc2]

Perhaps it would make sense to install it as /usr/bin/python-dotenv? That's what Debian does: https://packages.debian.org/buster/all/python3-dotenv/filelist but I don't know how they do it.

I'm not very familiar with that kind of situation. Let me know if there's something we can do to improve in the package. I'm not sure we should rename the dotenv executable installed by default (e.g. with pip install python-dotenv[cli]).

[hartwork]

Perhaps it would make sense to install it as /usr/bin/python-dotenv? That's what Debian does: https://packages.debian.org/buster/all/python3-dotenv/filelist but I don't know how they do it.

Debian has this code in a Makefile named debian/rules of the related packaging that does the renaming:

override_dh_auto_install:
	find . -name '.nx_file' -delete
	dh_auto_install
	mv debian/python3-dotenv/usr/bin/dotenv debian/python3-dotenv/usr/bin/python-dotenv

If you're up for adopting that naming upstream, it would fix the issue and users of Debian and Debian-based distros like Ubuntu will not experience any change. It would also communicate clearly, which dotenv users are dealing with. What do you think?

PS: Great idea to look at Debian's packaging 👍

[bbc2]

find . -name '.nx_file' -delete

Ouch, I hadn't realized this was a problem downstream. #340 should fix it.

If you're up for adopting that naming upstream, it would fix the issue and users of Debian and Debian-based distros like Ubuntu will not experience any change. It would also communicate clearly, which dotenv users are dealing with. What do you think?

It could be a good thing overall but it's not an obvious benefit for Python developers. In any case, it wouldn't happen overnight. If we do this, there will be a transition period with two executables available, so my advice would be to handle the renaming downstream in the meantime.

[hartwork]

[..] so my advice would be to handle the renaming downstream in the meantime.

Done (gentoo/gentoo@d4beda2)

[hartwork]

Any news on a potential rename of the CLI command?

[bbc2]

Not really but I did some research to understand the situation better:

• Gentoo: python-dotenv with command python-dotenv (source)
• Debian: python3-dotenv with command python-dotenv (source)
• Arch Linux: python-dotenv with command dotenv (source)
• Fedora: python-dotenv+cli with command dotenv (source)
• Ubuntu: python3-dotenv-cli with command dotenv (source) where it's in conflict with ruby-dotenv
• FreeBSD: py38-python-dotenv with commands dotenv and dotenv-3.8 (source)

[jhgit]

* Fedora: `python-dotenv+cli` with command `dotenv` ([source](https://koji.fedoraproject.org/koji/rpminfo?rpmID=27590807))

Fedora: There is also a godotenv package (no conflict due to the name of the CLI tool being bin/godotenv). Fedora does not seem to have a package for the rubygem flavor of dotenv.

* FreeBSD: `py38-python-dotenv` with commands `dotenv` and `dotenv-3.8` ([source](https://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/py38-python-dotenv-0.19.1.txz))

FreeBSD: The ports www/python-dotenv and misc/rubygem-dotenv have a documented and unresolved conflict due to both wanting to install bin/dotenv. So you can't install them both at the time of this writing. The ruby flavor was added in 2013. The python flavor was added in 2018.

[jhgit]

The dotenv script in the python-dotenv package appears to be more featureful than the rubygem version (list, set, get, run for the python flavor vs. just [essentially] run for the ruby flavor). But the two versions are certainly not drop-in compatible.

I don't know any software that is dependent on the bin/dotenv script (vs. the python or rubygem library). That doesn't mean there isn't a dependency - I just have not seen one yet.

I think it would be helpful to just rename the dotenv script in python-dotenv to py-dotenv or dotenv-py. But I don't know if any consumers would be affected.

Regarding provenance, if you just look at history of "first commit" in git repos, the ruby version precedes the python version (2012 vs 2013).