Recommend packaging name alternative(s)

[alerque]

Related to #18

I was on Repology today and the slice scene has an identity crisis. When I packaged for Arch Linux there were no name conflicts on slice and it was a shoe-in to just use that name. I see the situation is different on Debian/Ubuntu where a long abandoned text templating project using set theory has taken up the Debian package name. The project is only available on archive.org and the last release was in 2002, but that doesn't mean the Debian namespace is going to clear out any time soon.

I'm inclined to suggest keeping the project and binary name as slice for now. I plan to keep that package name in Arch unless something changes. But no matter how much we want it that still leaves the Debian package namespace with a conflict. Any attempt to package this for Ubuntu is going to run into this issue.

I suggest this upstream project come up with an suggested name for packages if/when conflicts arise. This way we don't end up with a bunch of downstream package names that aren't coordinated.

I've suggested to Repology that they rename the legacy project asci-slice or wml-slice, but that only solves the issue for their display system. Any Debian family packages will still need some alternative name to disambiguate themselves.

[chrissimpkins]

the slice scene has an identity crisis

I love that we are now part of the scene. :)

that still leaves the Debian package namespace with a conflict
I suggest this upstream project come up with an suggested name for packages if/when conflicts arise

We are using sourcefoundry-slice for the Homebrew package. Another alternative is slice-gui. It would be nice to be consistent everywhere, but I think it is ok if they are not so long as we have the package names documented for users. Thoughts?

[alerque]

Downstream packagers are under no obligation to follow suit, but if we hint at a preference –even if that is by just explicitly documenting the existing alternate(s)– most others will follow suit.

[chrissimpkins]

Sgtm. Is this something that is appropriate for this section of the docs? https://slice-gui.netlify.app/docs/install/#linux-packages

[chrissimpkins]

Or we also have Developer docs @ https://slice-gui.netlify.app/docs/developer/

Maybe a new package manager section?

[alerque]

I did not realize there was a conflict on PyPi to. How about just rebranding to be slice-gui (or slicegui if renaming on PyPi is a problem) across the board — GitHub project, installed binary, Python package, distro packages, everything? Would that be bad for any reason? It would sure side step the whole current and many potential future naming conflicts.

[chrissimpkins]

Hmm... I'm not a fan of the name "Slice GUI" for the GUI application or the repository tbh. It is a package naming workaround for the namespace conflicts in the package managers and I'd prefer not to have the package namespaces define the application/project name.

The project wasn't accepted in upstream Homebrew cask because they have popularity criteria. And their docs recommend that custom taps use a sure to be distinct name to avoid conflicts with anything that lands in the upstream. I went with sourcefoundry-slice there because we use a custom Source Foundry tap. It is ugly but it is only used with a brew install step on the command line. Then the user launches the application with the desktop icon. I recognize that the general Linux user has much more famiilarity with the command line, but I'd like to be able to support a similar icon clickable launch approach in Linux distros. This is a GUI app that is designed for use in a desktop environment. There will be no attempt to maintain a public library API or command line executable approach (both already supported in fonttools).

For the installed Python executable / pypi, I am doing my best to steer users away from installing the application with pip and launching it with the command line executable name. I recognize that this is how we are doing it with Linux distros (except Arch) right now, but we do have the ability to support a PyInstaller frozen build to a single-file "Slice" application bundle with all dependencies included as part of a distributed slice* executable. We should be able to support distribution with desktop icons for Linux users who use the desktop rather than launching the application from the command line. I also think that it will be important to package this with the upstream defined version of fonttools as we land things like #32 which has not been released in fonttools yet. This will lead to problems in distros that do not have the tip of the spear packages unlike Arch. I can make the PyInstaller spec to support this, but I don't have an approach to build a common set of architecture / distro package combinations for distribution of packages on this repo. I'm a bit torn about whether we would even want to do this, but it would allow us to define consistent Linux distro package names rather than provide guidance on the name to use, provide source/ guidance to those who might want to develop official packages based on the repository packages, and avoid the need (for me, perhaps you or someone else who wanders across this thread are interested in maintaining other packages?) to maintain official packages.

[chrissimpkins]

Thoughts about #27 (comment) Caleb?

[alerque]

I don't have any experience with PyInstaller and don't tend to like containerized app approaches where upstream projects build the container. I do see how they are actually useful for end users on distros that tend towards the stale and make upgrading a big ordeal. Looking at you Ubuntu.

That being said I don't think any of that works around the naming problem. Whether we work out prebundled packages here upstream or let downstream take care of itself in the end the packages still need to avoid naming conflicts on a per disto basis. Even if the desktop app calls itself "Slice" the system package name an executable still need to be disambiguated. Both still need to be "slicegui" or similar in Debian land. Hence I don't see why the repo & binary name shouldn't match even if the title of the GUI app eschews the "GUI" bit.