Created an issue: https://issues.apache.org/jira/browse/CASSANDRA-20679
On Sun, 25 May 2025 at 12:57, Mick Semb Wever <m...@apache.org> wrote: > > > Coming back to this. There is no clear path forward looking at folks' > preferences. > > The docker approach sounds beneficial, but comes with a few challenges that > haven't been addressed. We don't have docker at the ant build.xml or > .build/*.sh level intentionally, with docker layered on at the > .build/docker/*.sh level. We would need docker be invoked inside another > docker command, and for jenkins this means three layers of docker-in-docker… > and I'm not comfortable with our code check `ant check`, that we especially > want to apply to newcomers, to become by default optional (just because > docker isn't installed/running). Also no one has stepped forward to offer > doing the work for a docker approach, so i think until it's thrashed out a > bit more and with some sense of ownership we should exclude it as an option. > > My suggestion is the quick fix in option 1, while working on option 2. > Maxim, do you want to create a jira ticket for option 2 and we can continue > that work there. Pending objections we can start on this. > > > > On Fri, 2 May 2025 at 20:01, Jordan West <jw...@apache.org> wrote: >> >> +1 to docker. It’s a relatively universal dependency at this point, allows >> for more repeatable builds, and doesn’t require installing software in the >> build. It’s not any more heavyweight that go or python and has less >> environment nuances. It lets us pick what python (or go) we use among many >> other benefits. >> >> +1 to skipping parts of the build w an info/warning if docker is missing. We >> should NEVER be installing software without promoting. >> >> +1 to unifying generation on python. Absolutely appreciate the work done by >> the go folks. Separate from that keeping the build simple to reason about is >> important. >> >> Jordan >> >> On Fri, May 2, 2025 at 05:54 Joseph Lynch <joe.e.ly...@gmail.com> wrote: >>> >>> On Fri, May 2, 2025 at 6:46 AM Mick Semb Wever <m...@apache.org> wrote: >>>> >>>> But layering in the ability to do it with docker is opposed to requiring >>>> the use of docker. i.e. I don't think we should make docker mandatory >>>> inside `ant check`. >>> >>> >>> I think if you don't have docker it could be reasonable not to build the >>> docs as part of ant check (the golang part of gen-doc could be skipped). >>> Docker is fairly standard build tooling these days since it obviates the >>> need to have the right versions of things on peoples systems (e.g. golang >>> or python). >>> >>>> >>>> There are two possible paths forward >>>> option 1) remove the auto-install, and just print the command the user >>>> needs to run to do the install, and/or how to skip that target. >>>> >>>> option 2) build on Maxim's contribution to rewrite it to >>>> python+virtualenv+jinja >>> >>> >>> I don't object to #2, but once you start talking about virtualenv and >>> python libraries you may want to be building that via docker as well as >>> libraries often have minimum requirements of python versions. >>> >>>> >>>> With option (2) i feel it would be a shame that the original work in >>>> https://github.com/apache/cassandra-website/tree/trunk/cqlprotodoc from >>>> our newly joined gocql community would be redone. I can only hope they >>>> understand and appreciate this *is* their work being carried forward, and >>>> our legitimate reasons for the golang to python rewrite (i.e. there's >>>> nothing against golang in the community). (I've cc'd them.) >>>> >>>> Otherwise, I'm entirely on the fence – all ears. Slightly leaning towards >>>> option (1). >>> >>> >>> Is there an option 3? gen-doc (specifically the part that uses golang) >>> requires docker, and if you don't have docker that component of the docs is >>> skipped? That seems to move towards a possible world where we could move >>> towards just one build requirement (docker) instead of 10? If you feel >>> strongly we should always try first with native and only ask people to use >>> docker if their system isn't running the right versions then 1 seems better >>> to me given we have existing functional code and the official builds would >>> have golang available. >>> >>> -Joey
