proposal for util renaming

[Tim Peters]

From John Belmonte, on the zodb-dev list:

"""
I'd like to propose a renaming of the utilities currently placed in /usr/bin. Rationale:

     * some items are generically named, such
       as "fstest". A packager may be forced to
       rename these, or put them in a /usr/bin/zope
       subdirectory, either of which would break
       compatibility with other distributions. This
       is the namespace pollution issue again.

     * for some items, such as "repozo", the relevant
       component cannot be discerned from the name.
       This isn't the case for most items, but even
       then the naming is ad hoc.

     * the .py extension is an implementation detail
       and shouldn't be exposed. The zconfig tool
       follows this already.

     * the proposed names allow discovery through
       shell command completion (for example,
       "zeo-<tab><tab>")

 fsdump.py zodb-fsdump
 fsrefs.py zodb-fsrefs
 fstail.py zodb-fstail
 fstest.py zodb-fstest
 repozo.py zodb-fsbackup
 zconfig zconfig-check
 zeopack.py zeo-pack
 runzeo.py zeo-run
 zeopasswd.py zeo-passwd
 mkzeoinst.py zeo-mkinst
 zeoctl.py zeo-ctl
 zdrun.py zdaemon-run
 zdctl.py zdaemon-ctl
"""

[ChrisW (chris-simplistix)]

The .py isn't an implementation detail on windows.

So, I'm in agreement, except the new files hsould still have .py extensions...

Chris

[John Belmonte (john-neggie)]

> The .py isn't an implementation detail on windows.

If that is the case, you must reconcile the "zconfig" tool, which has no such extension.

By the way, my zodb package submission to Debian was rejected due to precisely this generic naming issue. I don't want to make user-visible changes local to the Debian distribution, so I hope this matter will be corrected in the near future.

[Tim Peters (tim-one)]

zconfig should have a .py extension on Windows -- all Python code should. The reason it doesn't is that Fred (zconfig's author) isn't a Windows programmer, and so is prone to making life needlessly difficult for Windows users. He's not alone in this, of course.

[John Belmonte (john-neggie)]

A clarification: I'm having trouble getting zodb accepted into Debian because of the /usr/bin/ namespace pollution, not the .py extensions. However, such extensions on scripts are discouraged.

Attached is a patch to remove the .py extensions under POSIX. What do you think? [Help: I can't attach a file to this issue!]

Regardless of .py extensions, I'd like to see the commands renamed before 3.3 beta. Shall I work on a patch?

[Steve Alexander (stevea)]

I have spoken to James Troup, who rejected the debian package. The main problem is the use of "fs" as an abbreviation for "FileStorage" in the ZODB executables.

"fs" is just too generic, and too likely to collide with other "filesystem" tools. I propose changing the "fs" to "zfs" in the names of the executables.

[Tim Peters (tim-one)]

Uploaded: posix_script_extension.patch

Attaching John's patch.

[Tim Peters (tim-one)]

Sorry, this won't happen for 3.3b1. That's scheduled for release tomorrow, and I'm overloaded already trying to get that done. This one needs more feedback from the community first. For example, how many admin scripts are out there using the current names? Are people happy to change them, or will they complain? Etc. It's generally a dangerous thing to change names this late in a release cycle. 3.4 is a different story.

[Chris McDonough (chrism-plope)]

I'm wondering why you would want to put the fs* commands in /usr/bin? Why not just carve out a namespace somewhere else in the directory tree and put them there? Does this violate the LFS somehow? I agree that conceptually it's a nice idea to have all commands in a single directory, but as far as I can tell you could probably get away with putting only these commands in /usr/bin (and maybe even a subset of these):

 repozo.py
 zeopack.py
 runzeo.py
 zeopasswd.py
 mkzeoinst.py
 zeoctl.py

[ChrisW (chris-simplistix)]

If your patch means that these scripts HAVE extensions on Windows and don't have them on Linux (I know Windows is POSIX sometimes, and not others (what is it in this case?)) then that's about a -5 for me.

Zope "works the same on all platforms" and that's a VERY good thing.

That said, I love debian. Could you not just put extensionless aliases where the yneed to go in debian (and where no Zope user needs to use them ;-) ?

[John Belmonte (john-neggie)]

> = Comment - Entry #10 by chrisw on Jun 1, 2004 3:53 pm
>
> If your patch means that these scripts HAVE extensions on Windows and
> don't have them on Linux (I know Windows is POSIX sometimes, and not
> others (what is it in this case?)) then that's about a -5 for me.
>
> Zope "works the same on all platforms" and that's a VERY good thing.

I'm not going to put up much of a fight about this as it isn't critical. That said, "works the same on all platforms" for command line tools is a fallacy, because for one thing, Windows and POSIX use different path separators. A command line tool should be defined by a name and an interface. Exposing the implementation of the command with a filename extension is bad design, and it's unfortunate to have Windows effectively imposing this upon the world.

> = Comment - Entry #9 by mcdonc on Jun 1, 2004 3:02 pm
>
> I'm wondering why you would want to put the fs* commands in /usr/bin?
> Why not just carve out a namespace somewhere else in the directory tree
> and put them there? Does this violate the LFS somehow? I agree that
> conceptually it's a nice idea to have all commands in a single directory,
> but as far as I can tell you could probably get away with putting only
> these commands in /usr/bin (and maybe even a subset of these):
>
> repozo.py
> zeopack.py
> runzeo.py
> zeopasswd.py
> mkzeoinst.py
> zeoctl.py

I'd be ok with that subset. It reduces the work for maintaining man pages too.

It's possible to put the remaining scripts elsewhere, such as in the doc directory, but execute permission is not allowed.

[Steve Alexander (stevea)]

The .py endings are not a problem on debian. They are not standing in the way of the package being accepted.

The unqualified use of "fs" in names in /usr/bin is standing in the way of the package being accepted.

[Steve Alexander (stevea)]

In addition, there were questions raised about the name "repozo.py". Surely there is a clearer name for this utility.

I think Tim's suggestion of thinking about names carefully for ZODB 3.4 is a good one.

[John Belmonte (john-neggie)]

> = Comment - Entry #13 by stevea on Jun 3, 2004 7:21 am
>
> In addition, there were questions raised about the name "repozo.py".
> Surely there is a clearer name for this utility.

Yes, I suggested zodb-fsbackup.

> = Comment - Entry #12 by stevea on Jun 3, 2004 7:19 am
>
> The .py endings are not a problem on debian. They are not standing in
> the way of the package being accepted.

I've never stated that they were in the way of the package being accepted, and in fact made it clear that it was "not critical" and that the practice was merely "discouraged".

> = Comment - Entry #11 by jbelmonte on Jun 2, 2004 12:50 pm
> > repozo.py
> > zeopack.py
> > runzeo.py
> > zeopasswd.py
> > mkzeoinst.py
> > zeoctl.py
>
> I'd be ok with that subset. It reduces the work for maintaining man
> pages too.

I'm having second thoughts about this being a viable solution. I don't see what the difference is between renaming something in /usr/bin and removing it. Existing users who access /usr/bin/fs* are going to experience breakage either way. May as well rename.

[ChrisW (chris-simplistix)]

> > In addition, there were questions raised about the name "repozo.py".
> > Surely there is a clearer name for this utility.
>
> Yes, I suggested zodb-fsbackup.

If that's what it does ;-)
(I've never had any idea what repozo.py does...)

> I've never stated that they were in the way of the package being
> accepted, and in fact made it clear that it was "not critical" and that
> the practice was merely "discouraged".

Cool, so lets have the .py's stay then :-)

> I'm having second thoughts about this being a viable solution. I don't
> see what the difference is between renaming something in /usr/bin and
> removing it. Existing users who access /usr/bin/fs* are going to
> experience breakage either way. May as well rename.

Yep, +1 from me :-)

[Hanno Schlichting (hannosch)]

These script renamings never happened, so apparently they haven't been all that important.