Rename showtable?

[olebole]

The name of the utility showtable is rather generic, and in Debian it actually generates a conflict with a utility written in Perl (and therefore cannot be packaged in the moment). Maybe there is a more specific name here?

Relevant Debian bug #891203.

[pllim]

xref #6859 by @saimn

[pllim]

Even if we rename here, showtable still needs to go through a deprecation period and will not be removed immediately. FYI.

[astrofrog]

@olebole - just to check, is there a mechanism for renaming showtable in the (astropy) Debian package?

[olebole]

@astrofrog I can give it any name in Debian; however it would be bad if we would use a different name than elsewhere - shell scripts would need to be rewritten etc. That's the reason of this issue.
@plim I am fine with any deprecation period as long as we have a clear new name. I can't use the old name anyway in Debian, so I would straightly use the new one.

[saimn]

The name is generic because the script is able to read a wide variety of formats: all ASCII formats supported by astropy, HDF5, FITS, VOTable. (And hence is much more generic than the Perl script from what I can see).
I'm not opposed to renaming it, if there is an agreement for this, but we need to find a good alternative name, that justifies deprecating and renaming something that has just been shipped and advertised.

What are the other solutions ?

• Not shipping showtable on Debian.
• Using alternatives ? (I guess no, probably reserved to cases where the script has exactly the same interface)
• Marking the packages as conflicting ? https://www.debian.org/doc/debian-policy/#conflicting-binary-packages-conflicts

[olebole]

@saimn It is generic in astrophysics, but not generally. Therefore, including "astro" somewhere in the name may be a solution. showastrotable?
Casacore also had once a showtable executable, and went into the same problem -- casacore/casacore#320.

• Currently showtable is not shipped in Debian because of that problem. There was however a request to include it (#891203).

• Debian "alternatives" are meant for different implementations of the same functionality -- /usr/bin/cc as being either gcc or clang

• Binaries with the same name are prohibited by Debian Policy 10.1. They also prevent the user to install both packages together which may be problematic (f.e. a user of perl:DataShow tries to install a program that depends on astropy, or vice versa).

Other distributions will run into the same problem (the casacore issue above was opened from the Gentoo guy, @sfabbro), so a Debian specific solution will not solve the general problem.

[pllim]

From the CASA ticket, I guess showtableinfo is taken as well...

[saimn]

Could be showastrotable, yes. Any other suggestion ?
ping @taldcroft @astrofrog @SaraOgaz as contributors of the original issue/PR.

[SaOgaz]

Naming things is so hard... can't say I have any suggestions.

[pllim]

Would showastropytable be more accurate? 🤔

[saimn]

Hmm, showastropytable may sound like "show the astropy table (format)" which i think is misleading. Part of the problem is that the script is generic enough that it cannot be "showfitstable" or "showasciitable" etc.
showastrotable is a bit better because it does not refer to a specific format.

[bsipocz]

And what about if it's being called showtable-astropy on debian, otherwise we keep whatever we have. I still don't see how we supposed to avoid all name clashes with other non python packages, and ultimately why can they but not us keep the name.
Can we know anything about whether the userbase have some cross-section, or this perl package is installed by default?

[olebole]

@bsipocz The problem with your proposal is that the experience with astropy will then be inconsistent: on some systems (not only Debian/Ubuntu, but also other distributions that can't live with a name clash) the tool is called showtable-astropy; on others it is called showtable. Will be fun to write tutorials and shell scripts utilizing this tool. Also, people who use the Perl showtable somewhere else in a script will have fun after they installed a "regular" astropy.

I still don't see how we supposed to avoid all name clashes with other non python packages

When you have Debian or Ubuntu available, a

$ apt-file search /usr/bin/showtable
casacore-tools: /usr/bin/showtableinfo
casacore-tools: /usr/bin/showtablelock
libdata-showtable-perl: /usr/bin/showtable

helps to find them among the 50.000 sofware packages that are in Debian. And they are really rare -- IMO this is the first time we have this problem, after 5 years of astropy. I did not expect this, otherwise I would do more regular checks here. If in doubt, you can also ask me (or check it on https://packages.debian.org/)

and ultimately why can they but not us keep the name.

They simple were first :-) And, independent of this: showtable is just very generic, even in astronomy. If you would have installed a astronomy data management framework (astrowise or such), what would you expect from showtable? Maybe one would more expect to see lists of raw/reduced files then?

Can we know anything about whether the userbase have some cross-section, or this perl package is installed by default?

It is not installed by default, and its user base is not very big. However we call for trouble if we keep the name clash. Let's not do that. The solution (new name) is still rather cheap; cheaper than in two years.

[cdeil]

Have you considered introducing a single command astropy with sub-commands, i.e. like how git or other tools work?

Namespaces are one honking great idea -- let's do more of those!

As a user, I always have difficulty remembering the names of the command line tools that come with Astropy, I would actually prefer to type astropy and have it print the available sub-commands, like git does.

I realise it's a matter of taste, the argument to keep separate commands is that they might be unrelated and the fact that they are implemented in Astropy shouldn't be exposed to the user. But it can be done in a backward-compat way (keep the old ones in addition for however long you like), and it would solve this name collision, so I thought I'd bing up the suggestion.

[olebole]

@cdeil I actually like this idea. Beside of solving the showtable problem, it also has much room of extension. And it makes things clearer. When you have a number of astronomy tools installed, you start to get confused, since there are a lot of tools with very similar names but coming from totally different places: fits2bitmap, fits2table, fitscheck, fits-column-merge, fitscopy, fitscut, fitsdiff, fits-flip-endian, fitsgetext, fits-guess-scale, fitshdr, fitsheader, fitsinfo, fitsmd5, fitsort, fitspng, fitstopnm, and fitsverify. Just to name those starting with "fits". Do you immediately guess which of those were from astropy?

So, 👍 from me.

[pllim]

Prepending astropy to the command only works if they will never, ever be moved out of Astropy. The FITS stuff was inherited from PyFITS, so adding astropy in front of them also introduces another barrier from people transitioning over (and not backward compatible).

[mhvk]

👍 to @cdeil's suggestion. And I definitely agree that With @olebole that we should rename now rather than later.

If we do want to keep the single name, as showastrotable is rather long, how about just astrotable? One advantage is that that name leaves more scope for expansion. E.g., it could do --show by default, but maybe --convert in future.

p.s. The old pyfits tools did start with fits....