harmonise names of package dirs in pkg/

[dimpase]

currently most are named like

  blah/

while the rest are named

  foo-1.2.3/

Do either way, but do not mix them.

[olexandr-konovalov]

Just to explain where these names come from - we use exactly the name of directory with the package provided by package authors in the package archive.

Even though there is a way to get the name of the package directory with DirectoriesPackageLibrary, I would be reluctant to rename these directories in case their name may be hardcoded somewhere in some legacy package (e.g. in GUAVA, see gap-packages/guava#7).

[dimpase]

Well, so someone long time ago was not careful enough to ensure this uniformity.
Does this mean that it must remain messy forever? (I presume no version numbers is the
way to go).

Hardcoded names can be fixed, it's not much effort.

[fingolfin]

Please explain what advantage this would have, resp. which problem with it you perceive - for now, this sounds to me like a mere question of aesthetics.

[dimpase]

e.g. scripts parsing names of packages can be kept cleaner, and we have such scripts in Sage...

[dimpase]

Apart from ease of automated handling and aesthetics (unless you want to intentionally create an impression that GAP is sloppy :-)), another reason is preserving packagers' sanity...

[olexandr-konovalov]

In the https://github.com/gap-system/GapWWW/blob/master/Download/InstPackages.sh, I am using packagename-* as soon as the package starts to use the foo-1.2.3 convention, and that seems to be an efficient long-term solution.

The other script https://github.com/gap-system/gap-distribution/blob/master/wininst/wininst.g to generate input for NSIS to build GAP installer for Windows uses GAPInfo.PackagesInfo.(pkg)[1].InstallationPath so is also completely fine with names of package directories.

We may have a recommended naming convention for package directories, but I see no reasons to strongly impose it.

[dimpase]

by the way, how do you handle package dependencies? If blah depends on foo, must blah use the version of foo, too? Or not?

[olexandr-konovalov]

@dimpase of course - https://github.com/gap-packages/example/blob/master/PackageInfo.g has component called Dependencies which allows to specify not only the package but also the minimal version number that should be used. Version numbers are well defined and comparable with CompareVersionNumbers (see here).

The only thing missing in this model is that the version should be at least N - you can not specify e.g. "any version between A and H except version D".

More on package dependencies here: http://www.gap-system.org/Manuals/pkg/example/doc/chapA.html#X7FB5FECD7C271688

[dimpase]

if you have all the version info stored elsewhere, what's the point of foo-1.2.3/ ? No, really?
The only reason would be to have several versions of the same package allowed to be installed, but this is not supported, right?

[ChrisJefferson]

@dimpase : There is no 'point' to foo-1.2.3, on the other hand, there is no reason to restrict packager's choice of directory.

Also, you can install multiple versions of the same package, and GAP will load (usually) the most recent one. I take advantage of this, by having (for example) semigroups, and then semigroups-dev in a separate package directory which I can choose to enable/disable.

[fingolfin]

I still don't understand how this makes the life of a packager harder, let alone how it could drive somebody to insanity: Using a regex foo*, you can cover both foo and foo-1.2.3 with minimal work.

While my sense of aesthetics is also not happy about this situation, my sense of practically tells me that this is one of the less (least?) important "issues".

[frankluebeck]

@dimpase wrote:

Well, so someone long time ago was not careful enough to ensure this uniformity.

No, it is the other way round. Many years ago these directories had to be named uniformly by the lower case version of the package name, in fact this determined implicitly the package name.

When all meta information about a package was moved into and collected in the PackageInfo.g file this became unnecessary. From then there was no restriction on the directory name and package authors got the freedom to use their preferred naming scheme.

In the current list of redistributed packages I can see no abuse of this freedom. In all cases it is clear to which package a directory belongs.

As a side effect of this improved flexibility it became possible to install several versions of a package in the same directory (convenient for package developers and users of dev-versions).

[olexandr-konovalov]

@ChrisJefferson, @frankluebeck thanks - I was going to add the same point about keeping several versions of the same package.

I suggest that we may close this issue.

[dimpase]

I'm sorry, I don't get it.

Does GAP as a distribution (we are in gap-distribution discussion!) support
multiple versions of the same package? No.

Are there GAP commands to support loading an explicit version of a package?
No.

A casual look at the current pkg/ sets one thinking like: "hmm, some
packages have versions, some don't".
Which is not the case. Well, this is my point about keeping things clean
and uniform. It seems you don't care about this, instead preferring to talk
about "freedom". Of course you have freedom to confuse your users, but DO
YOU WANT TO?

On 20 January 2016 at 10:05, Alexander Konovalov notifications@github.com
wrote:

@ChrisJefferson https://github.com/ChrisJefferson, @frankluebeck
https://github.com/frankluebeck thanks - I was going to add the same
point about keeping several versions of the same package.

I suggest that we may close this issue.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[frankluebeck]

@dimpase wrote:

Does GAP as a distribution (we are in gap-distribution discussion!) support multiple versions of the same package? No.

support: yes, distribute at the same time: no.

Are there GAP commands to support loading an explicit version of a package? No.

Of course, yes. Please read the help section on LoadPackage.

A casual look at the current pkg/ sets one thinking like: "hmm, some packages have versions, some don't".

Indeed, you don't get it. The directory name is not the place to find out a package name or version number. All packages have versions. Consult the PackageInfo.g files for this information.

[dimpase]

On 20 January 2016 at 11:03, frankluebeck notifications@github.com wrote:

@dimpase https://github.com/dimpase wrote:

Does GAP as a distribution (we are in gap-distribution discussion!)
support multiple versions of the same package? No.

support: yes, distribute at the same time: no.

Are there GAP commands to support loading an explicit version of a
package? No.

Of course, yes. Please read the help section on LoadPackage.

A casual look at the current pkg/ sets one thinking like: "hmm, some
packages have versions, some don't".

Indeed, you don't get it. The directory name is not the place to find out
a package name or version number. All packages have versions. Consult the
PackageInfo.g files for this information.

Well, I didn't know that, but then the common sense would be to always
include version numbers in the
packages' paths. And currently it is not the case. As well, it leaves
questions unanswered.

E.g. what is the relationship between names of package directories and
package versions?
Does version in the path matter? Does it matter more (or less?) than the
version number in the package info?

If you really want to allow freedom on the naming, you have to document it
accordingly. IMHO it's much easier for everyone to enforce the uniformity.

[dimpase]

As there were questions about the point of enforcing the directory names, e.g. by @fingolfin , let me
point out that if package versions were always matching directory names, the code of
InitializePackagesInfoRecords and other related function would be much cleaner and more efficient.

Emulating by plain text files things that are best encoded by the filesystem is certainly bad design, and it simply did not cross my mind that this design has been chosen...

[olexandr-konovalov]

@dimpase wrote:

If you really want to allow freedom on the naming, you have to document it accordingly. IMHO it's much easier for everyone to enforce the uniformity.

There is an open pull request gap-system/gap#484 with the guidance to package authors - you may leave a comment in the code there suggesting formulations of recommendations to package authors regarding the choice of the directory name for the package. We may explain that including version numbers in the packages' paths is preferable and explain why, but say that this is not mandatory. This is perhaps the only practical outcome of this issue.

[olexandr-konovalov]

I will close this issue - we use names of the directories chosen by authors "as is". If you'd like to add a couple of sentences to the guidance to package authors, telling them what you consider to be a good practice, please leave them under gap-system/gap#484

[dimpase]

I am asking for introducing a formal naming rule, and you tell me about good practice etc etc.
Do you understand the difference?

[fingolfin]

We have asked you to provide arguments why this should be done, and you failed to deliver. Instead, you bring up claims that are simply false, and indicate that you did not even bother to read the documentation.

Hence, we rejected your request for a formal naming rule, because you failed to provide any actual evidence that there is a need for this.

[dimpase]

Actual evidence is in ease of creating, extending, and maintaining GAP packages to be distributed with Sage.
I can demonstrate my tennis/mouse/keyboard elbow, as one piece of evidence that this is not exactly trivial now.

And another piece is OpenDreamKit/OpenDreamKit#51 - IMHO one has to deliver something promised there, but we cannot even agree on the directory structure and the need to eliminate crap from directories, I don't feel like continuing this.