Support CS flavor starting with 7.4

[greghendershott]

After 7.4 is released (likely in a couple weeks), will need to think about how to treat CS going forward.

Which should it be:

1. Distinct targets like RACKET_VERSION = 7.4 and (say) RACKET_VERSION = 7.4-CS

2. CS is an "modifier flag" like RACKET_MINIMAL and RACKET_NATIPKG.

Although 2 seems nicer, I think having both CS and non-CS builds is intended to be a short-term plan. That is, at some point Racket would just switch over to the CS implementation. That would seem to favor doing 1, because the whole CS-or-not distinction will end up applying to only a few versions of Racket?

Welcome anyone to comment!

[greghendershott]

The lack of comment suggests that no one is still using this. As a result, it could be another Racket-related repo that I can archive.

Or, if people are still using this, then would one of you like to take the baton from me? If I understand correctly, we could reassign the repo to you (or to a GitHub org) and it will redirect requests from this URL to the new one.

[jarcane]

I am still using this for Heresy, and I had the same question the other day, I just hadn't yet had time to seek the answer. I'm not really that great with Travis so I wouldn't be sure where to start implementing it or how.

[greghendershott]

ISTR on Racket Slack some months ago, someone said they wanted to make official Travis CI language support for Racket. IIUC Travis CI wants three people to commit to be maintainers. I believe I said something like, "OK, well I'm glad to keep travis-racket working until you find the other two people (I don't want to be one of them) and make that happen."

But I'm no longer glad to do it. I think someone else should take a turn doing it for awhile. (Plus I'm not super motivated to keep doing it, when I'm not even using it myself anymore: Currently I have no plans to install Racket 7.4 or update packages to work with it. Although that might change someday it also might not.)

[jarcane]

In that case I will try and take a look when I can, as if nothing else, absent official support, this is still the only way I can get easy CI for Heresy.

[LiberalArtist]

First, thanks, @greghendershott, for creating and maintaining this over the years. I for one am definitely using it, and I think there are in fact some strengths for this approach vs. relying on first-party integration from Travis or other CI services. Personally, I didn't comment on this issue earlier because I didn't see it (until just now I didn't "watch" this repository, despite having made a PR or two), which I think is a testament to the fact that install-racket.sh and the example .travis.yml largely "just work" and can easily be taken for granted as part of the Racket ecosystem.

In principle, I would be willing to take on maintainership if you would like (or to be one of a few people to do so).

I can think of a few things that perhaps should be addressed if there is going to be a transition:

1. One thing is the repository URL, which is referenced not just by people's existing CI config but also by raco pkg new: https://github.com/racket/racket/blob/38ef00fca3524b026655f2f3a30b2adebba934b0/racket/collects/pkg/private/new.rkt#L159-L162 If you're right that the current URL can be preserved, that would probably be ideal.
   It is not great that raco pkg new essentially inlines the example .travis.yml from this repository, since people (including me) often forget that it has to be updated separately. I don't know if there is a better solution than just trying to remember that.

2. I just noticed that there isn't a license in this repository. I think something like Apache 2 would probably be suitable, and the clarity might make some people more comfortable.

In terms of the actual subject of this PR, I think I agree with you that:

Although 2 seems nicer, I think having both CS and non-CS builds is intended to be a short-term plan. That is, at some point Racket would just switch over to the CS implementation. That would seem to favor doing 1, because the whole CS-or-not distinction will end up applying to only a few versions of Racket?

I would be inclined to add a special case for RACKET_VERSION = 7.4-CS and likewise for the next few(?) releases. I think there may still be official non-CS builds after CS becomes the default, and at that point a modifier might make more sense, but at that point you would also want CS to be the default, and changing the behavior of a modifier would not be nice.

More generally, I definitely agree with your comment elsewhere that:

… I feel like adding the macOS "dimension" means the conditionals and permutations is getting to be a slightly heavy cognitive load.

A while ago, I wanted to do CI on Windows for some of my Racket projects that have native dependencies. My initial attempt, just barely good enough to get something working, is at https://github.com/LiberalArtist/appveyor-racket: it is heavily based on your install-racket.sh.
Even without trying to support nearly as much as you do, I found the cognitive load got heavy quickly. I have actually been experimenting with some alternatives, and I have a half-written attempt at a multi-platform install script in Ruby, which provides more means of abstraction than Bash but also seems to be included in all CI services' default environments. (I believe one of the Windows ones lacked Python.) Whether that specific direction works out or not, if I were going to add significant features (as opposed to maintaining roughly the existing level of functionality), I would want avoid making the Bash conditionals any more complicated.

[greghendershott]

@LiberalArtist Thanks for the feedback and offer!

One quick thought: Much of what install-racket.sh does is fill a void -- the absence of a redirect server with logical URLs, which the core Racket team has so far been unwilling or unable to provide themselves.

That is, something like download.racket-lang.org/{version}/{platform}/{flavor like minimal} would redirect to NEU or NW or wherever.

• If the core team releases a new version, they add it.
• If the core team is having a server issue (e.g. "Winooski"), they just change the redirect.

As opposed to:

• Having a redirect server in the form of a big case statement in install-racket.sh.
• Someone like you or me having to notice and eventually update it days or weeks later.

Maybe after such a change install-racket.sh and this repo still exist in a simplified form, or not, I don't know.

[greghendershott]

I found time to look at this again.

• Their approach with the URLs seems to be treating "-cs" as an optional suffix following the optional suffix "-natipkg". So, contrary to the discussion above, I'm going to treat it as a "flavor", following their lead.

• I added a FUNDING.yml to this repo as an additional mechanism to signal usage as well as interest in ongoing maintenance. (To be clear, I intend this only for the special case where the repo has financial value to an individual or organization.)

[greghendershott]

Speaking of these "flavors", I realized that test.sh wasn't exercising all possible permutations.

I searched the download pages to confirm that

• "minimal" was there going back 5.3.1 (albeit called "textual") originally
• "natipkg" was added starting in 6.5
• "cs" of course was 7.4

And changed the script to iterate among all these.

I won't open a separate issue for that, but I just pushed it as commit 2cc8138 to the same branch as commit b438731 and will merge both to master.

[LiberalArtist]

I thought I'd leave a pointer here to an ongoing racket-dev thread on CI. @samth has also created a #ci Slack channel.