Which packages do not have a known public repository

[olexandr-konovalov]

This is a list of packages (from GAP 4.9.3 release) without known (to us) public repository. Please help to reduce it - by letting us know if the repository exists, of if you're a package author, by establishing it.

• atlasrep
• automgrp https://github.com/gap-packages/automgrp
• browse
• corelg https://github.com/gap-packages/corelg
• crime https://github.com/gap-packages/crime
• ctbllib
• cubefree https://github.com/gap-packages/cubefree
• design https://github.com/gap-packages/design/
• gbnp https://github.com/gap-packages/gbnp/
• grape https://github.com/gap-packages/grape/
• hap https://github.com/gap-packages/hap
• hapcryst https://github.com/gap-packages/hapcryst/
• help https://github.com/gap-packages/HeLP
• liering https://github.com/gap-packages/liering
• nilmat https://github.com/gap-packages/nilmat
• polymaking https://github.com/gap-packages/polymaking/
• quagroup https://github.com/gap-packages/quagroup
• rds https://github.com/gap-packages/rds/
• repsn https://github.com/gap-packages/repsn
• sla https://github.com/gap-packages/sla
• smallsemi https://github.com/gap-packages/smallsemi
• spinsym https://github.com/gap-packages/spinsym
• tomlib https://github.com/gap-packages/tomlib

We offer help in migrating your package to GitHub, and we can prepare for you a repository with revisions history populated from the past releases of your package, which may be very useful to see when changes were introduced.

Packages with public repositories are getting more help from the GAP developers, because:

• they are more visible
• it's easy to submit changes via a pull request
• we can run tests for the development version of the package to check that changes in GAP do not break tests in the package.
• the author/maintainer keeps admin rights on the repository, and has the lead role in technical decisions, but if asked, several other GAP team members may publish a release and update the website for you.

Having a public repository on GitHub helps a lot to authors/maintainers who want to overlook to the package, but do not want to be involved in technicalities of publishing releases.

To run regular tests for packages with known public source code repositories, I've set up a Travis test at https://travis-ci.org/gap-packages/gap-docker-pkg-tests-master-devel. This service provides an opportunity to test changes that have been made in a GAP package but are not yet included into its official release, for their compatibility with the current development version of GAP and with other GAP packages prepared for the next GAP release. You can see the README https://github.com/gap-packages/gap-docker-pkg-tests-master-devel for further details.

[fingolfin]

automgrp repository is here: https://sourceforge.net/p/finautom/code/HEAD/tree/

[olexandr-konovalov]

tomlib repository is now at https://github.com/gap-packages/tomlib

[olexandr-konovalov]

Next we have:

• design https://github.com/gap-packages/design/
• grape https://github.com/gap-packages/grape/

[olexandr-konovalov]

Work in progress: corelg, liering, quagroup, sla for @willemdegraaf

[olexandr-konovalov]

HeLP repository is at https://github.com/gap-packages/HeLP

[olexandr-konovalov]

liering, quagroup, sla by @willemdegraaf et al. now have public repositories.

[olexandr-konovalov]

Work in progress: cubefree for @heikodietrich

[olexandr-konovalov]

Welcome to the next two:

• corelg https://github.com/gap-packages/corelg
• cubefree https://github.com/gap-packages/cubefree

Thus, we already have repositories for 11 out of 23 packages listed above.

[olexandr-konovalov]

Work in progress for HAP and HAPcryst - thanks @grahamknockillaree!

[olexandr-konovalov]

Work in progress - REPSN package.

[olexandr-konovalov]

REPSN package: check! https://github.com/gap-packages/repsn

[olexandr-konovalov]

Work in progress: polymaking, hapcryst and rds - thanks @marc-roeder!

[olexandr-konovalov]

HAP package: check! https://github.com/gap-packages/hap

[olexandr-konovalov]

Welcome to:

• https://github.com/gap-packages/hapcryst/
• https://github.com/gap-packages/polymaking/
• https://github.com/gap-packages/rds/

[olexandr-konovalov]

Work in progress: spinsym - thanks @maasluk!

[olexandr-konovalov]

Welcome to:

• @maasluk and spinsym repository at https://github.com/gap-packages/spinsym
• @jwknopper and GBNP repository at https://github.com/gap-packages/gbnp/

[olexandr-konovalov]

Welcome to smallsemi: https://github.com/gap-packages/smallsemi CC @james-d-mitchell @fingolfin

[olexandr-konovalov]

Excited to see new release of Smallsemi at https://gap-packages.github.io/smallsemi/ - thanks @james-d-mitchell and @fingolfin!

[olexandr-konovalov]

@frankluebeck @ThomasBreuer do you have public repositories for AtlasRep, Browse and CTblLib?

[ThomasBreuer]

There are no public repositories for AtlasRep, Browse, and CTblLib.

[fingolfin]

@ThomasBreuer are there any plans to change that? Or are their repositories deliberately kept private? (BTW, some projects also use a mixture: they have a public repository, but only for release, issue tracking etc., but development happens in a private fork of the repository)

[olexandr-konovalov]

AutomGrp moved to https://github.com/gap-packages/automgrp - thanks @dsavchuk @fingolfin

[olexandr-konovalov]

@fingolfin have you been in touch already with the authors of

• FinInG: Finite Incidence Geometry (git repository)
• Forms: Sesquilinear and Quadratic forms (mercurial repository)

hosted on Bitbucket, by any chance?

[fingolfin]

https://bitbucket.org/jdebeule/forms/issues/4/migrate-package-to-git-and-or-another-vcs

[olexandr-konovalov]

Nilmat is now at https://github.com/gap-packages/nilmat

[olexandr-konovalov]

@ThomasBreuer thank you for the reply. Are there any plans to establish public repositories for AtlasRep, Browse, and CTblLib? How can we help?

[olexandr-konovalov]

@ThomasBreuer @frankluebeck the mentioned package use some obsolete variables e.g. USER_HOME_EXPAND, STRING_LIST_DIR , InfoRead1, TRANSDEGREES - having a repository would be helpful to report this to you and to submit a PR to remove them...

[ThomasBreuer]

@alex-konovalov From the text of your comment, I assume that "the mentioned package" is Browse.

I disagree with your statement.
Frank and I are aware of the fact that the current version of Browse uses some variables which you mention, and we know how to address the fact that they will be obsolete, in a forthcoming version of GAP.
Thus nothing needs to be reported, and a pull request would not be helpful.

When a GAP version will be available that allows us to replace the use of these variables, we can think about a new Browse version, but not before.

[olexandr-konovalov]

@ThomasBreuer First, there was a typo: package -> packages, since obsolete variables happen in all of the three (AtlasRep, Browse, and CTblLib) packages. This is from the output of make testobsoletes in stable-4.11 branch, and it involves all three packages.

Syntax warning: Unbound global variable in /circa/scratch/gap-jenkins/workspac\
e/GAP-pkg-update-stable-quicktest/GAPCOPTS/64build/GAPGMP/gmp/GAPTARGET/obsole\
tes/label/kovacs/GAP-pkg-update-stable-snapshot/pkg/atlasrep/gap/access.gi:256\
8
        firstarg:= USER_HOME_EXPAND( firstarg );
                   ^^^^^^^^^^^^^^^^
Syntax warning: Unbound global variable in /circa/scratch/gap-jenkins/workspac\
e/GAP-pkg-update-stable-quicktest/GAPCOPTS/64build/GAPGMP/gmp/GAPTARGET/obsole\
tes/label/kovacs/GAP-pkg-update-stable-snapshot/pkg/Browse/app/filetree.g:21
    files:= STRING_LIST_DIR( USER_HOME_EXPAND( startfile ) );
            ^^^^^^^^^^^^^^^
Syntax warning: Unbound global variable in /circa/scratch/gap-jenkins/workspac\
e/GAP-pkg-update-stable-quicktest/GAPCOPTS/64build/GAPGMP/gmp/GAPTARGET/obsole\
tes/label/kovacs/GAP-pkg-update-stable-snapshot/pkg/Browse/app/filetree.g:21
    files:= STRING_LIST_DIR( USER_HOME_EXPAND( startfile ) );
                             ^^^^^^^^^^^^^^^^
Syntax warning: Unbound global variable in /circa/scratch/gap-jenkins/workspac\
e/GAP-pkg-update-stable-quicktest/GAPCOPTS/64build/GAPGMP/gmp/GAPTARGET/obsole\
tes/label/kovacs/GAP-pkg-update-stable-snapshot/pkg/ctbllib/gap4/ctadmin.tbi:1\
14
      name:= USER_HOME_EXPAND( name );
             ^^^^^^^^^^^^^^^^
Syntax warning: Unbound global variable in /circa/scratch/gap-jenkins/workspac\
e/GAP-pkg-update-stable-quicktest/GAPCOPTS/64build/GAPGMP/gmp/GAPTARGET/obsole\
tes/label/kovacs/GAP-pkg-update-stable-snapshot/pkg/ctbllib/gap4/ctadmin.tbi:1\
17
      InfoRead1( "#I", READ_INDENT, "Read( \"", name, "\" )\n" );
      ^^^^^^^^^
Syntax warning: Unbound global variable in /circa/scratch/gap-jenkins/workspac\
e/GAP-pkg-update-stable-quicktest/GAPCOPTS/64build/GAPGMP/gmp/GAPTARGET/obsole\
tes/label/kovacs/GAP-pkg-update-stable-snapshot/pkg/ctbllib/gap4/ctadmin.tbi:1\
21
        InfoRead1( "#I  Read( \"", name, "\" ) done\n" );
        ^^^^^^^^^
Syntax warning: Unbound global variable in /circa/scratch/gap-jenkins/workspac\
e/GAP-pkg-update-stable-quicktest/GAPCOPTS/64build/GAPGMP/gmp/GAPTARGET/obsole\
tes/label/kovacs/GAP-pkg-update-stable-snapshot/pkg/ctbllib/gap4/ctdbattr.g:24\
84
      NrMovedPoints, [ 2 .. TRANSDEGREES ],
                            ^^^^^^^^^^^^

Second, you wrote:

I disagree with your statement.
Frank and I are aware of the fact that the current version of Browse uses some variables which you mention, and we know how to address the fact that they will be obsolete, in a forthcoming version of GAP.
Thus nothing needs to be reported, and a pull request would not be helpful.

When a GAP version will be available that allows us to replace the use of these variables, we can think about a new Browse version, but not before.

In reply to me saying

having a repository would be helpful to report this to you and to submit a PR to remove them...

Just to reiterate, I stated that it will be helpful to ME if there will be a repository - that is, a default place where I and other developers and users can submit issues and PRs. Of course, you can disagree and say that it will not help me at all, but I will stay convinced that it will, and here is why.

Not having a default issue tracker for a package leads to issues being created all over the place, e.g. in the main GAP repository, or emailed to package authors. As a result, it's hard to find them. Therefore, other people willing to report them will not easily see that they were already reported, what will cause duplication of efforts and waste of time. Even more, it could happen that someone will post their own suggestion again, forgetting that they already did that in the past.

To the contrary, keeping issues closer to code will help to discover them. The same is about pull requests - there is no obligation for package authors to merge them, but they can be discussed and reviewed, and if you have a different plan (e.g. wait for GAP 4.11) then you would be able to state that in your comments.

Over the last several years, having a public repository and a public issue tracker became a widespread practice among GAP packages, and by now AtlasRep, Browse, and CTblLib are the only three packages redistributed with GAP which do not have them. With them, we would be able e.g. to automate the process of getting all development versions of all GAP packages (e.g. using the new PackageManager package), or to run daily tests of their development versions at https://travis-ci.org/gap-infra/gap-docker-pkg-tests-master-devel to ensure that changes in GAP do not break tests in these packages.

There are various ways to set this up. For example, you can even have a public issue tracker and a public repository together with and private repository, and push things to the public one periodically, keeping the development version in a branch in your private repository. We can even set up new repositories for you, populating them from releases history, or help with converting existing ones if they use another version control system - just let us know if you would like to proceed.

[ThomasBreuer]

@alex-konovalov I think there are at least two aspects which you mix up in your message.

First, there is the "issue" of obsolete variables. This is well-known, and it is not helpful to repeat it again and again. In general, I do not see any benefit in removing variable names, just the contrary, I regard it as user-unfriendly in the sense that old GAP code (published in papers, available at users' homepages, or just privately exchanged via e-mail) is likely to get broken on purpose. In particular, I do not regard the exchange of such variable names as a reason for a package release.
(Actually, I have an archive of a new CTblLib version, which relies on some features of GAP 4.11, thus this version can be released as soon as GAP 4.11 becomes available.)

The second aspect is that of package management, and I am not sure whether the appropriate place for such a discussion is here.
Concerning the automation of package management, I do not think that it is necessary to force a particular way how a package has to be developed, I would even not assume that a "development version" of a package exists.