Re: [NEW] textproc/go-chroma

Attached is the version without the playground. Unfortunately it still
needs a custom distributable due to the project using Go submodules,
but at least now it's "make dist"-able because it doesn't require any
non-OpenBSD utilities.

The port now also additionally sets "commit" and "date" variables. I'm
not sure if this is frowned upon, because I haven't seen any other (Go)
port do this, but you can just remove it if it's too much.

Happy testing the new version!

On Thu, 2026-07-09 at 11:11 +0100, Stuart Henderson wrote:
> On 2026/07/08 23:24, Igor Zornik wrote:
> > Hello again.
> > 
> > > To me, this feels more like a demo of how to use the code than
> > > something that most people would run themselves. If that's the
> > > case,
> > > then packaging it is probably overkill (and maybe even a bad idea,
> > > if
> > > it hasn't been coded defensively enough to run as an internet-
> > > facing
> > > service).
> > 
> > Sort of like that. It's a playground like the title suggests. So I
> > guess your vote is option number 2 (total removal, not merging and
> > not
> > separating it in a subpackage). I'll start working on it like that
> > unless I hear any objections.
> > 
> > > Also, as-is the rc script runs it as root, which is not good. But
> > > until we either have dynamic uid allocation or figure out some uid
> > > range that we can extend into for ports that doesn't cause big
> > > problems for too many people, individual uids for ports are a
> > > scarce
> > > commodity. I think this is probably not useful enough to use one
> > > up
> > > on.
> > 
> > Don't scare me like that. It's actually running as www. I've just
> > rechecked with top:
> 
> Oh, I was going by the lack of @newuser in PLIST.
> 
> Ports are not generally meant to run as www either though
> 
> > 6751 www 2 0 85M 13M sleep/1 kqread 0:00 0.00% gochromad
> > 
> > On Wed, 2026-07-08 at 17:18 +0100, Stuart Henderson wrote:
> > > On 2026/07/08 18:11, Igor Zornik wrote:
> > > > Hello,
> > > > 
> > > > > I don't see a reason to split them out to a subpackage;
> > > > > include
> > > > > the
> > > > > files in the main package if they're useful, or drop them if
> > > > > not.
> > > > 
> > > > Indeed, but apparently that's a bit subjective so who exactly
> > > > decides what is useful? Maintainer or reviewers/approvers? For
> > > > additional context, what "-web" does is it basically runs this
> > > > website
> > > > https://swapoff.org/chroma/playground/ on your local machine.
> > > > 
> > > > When I make a port, I try to be fair towards both project
> > > > developers
> > > > and ports consumers, so I try to include the project in its
> > > > entirety.
> > > > It is through a discussion on the ports mailing list with
> > > > knowledgable
> > > > and authoritative people that we conclude if or what is
> > > > appropriate
> > > > to
> > > > commit into the ports tree and what to omit.
> > > 
> > > Yes.
> > > 
> > > To me, this feels more like a demo of how to use the code than
> > > something
> > > that most people would run themselves. If that's the case, then
> > > packaging
> > > it is probably overkill (and maybe even a bad idea, if it hasn't
> > > been
> > > coded defensively enough to run as an internet-facing service).
> > > 
> > > Also, as-is the rc script runs it as root, which is not good. But
> > > until
> > > we either have dynamic uid allocation or figure out some uid range
> > > that
> > > we can extend into for ports that doesn't cause big problems for
> > > too
> > > many people, individual uids for ports are a scarce commodity. I
> > > think
> > > this is probably not useful enough to use one up on..
> > > 
> > > > Currently I see three options for -web. I'm fine with any, but
> > > > obviously
> > > > hold a preference for the 1st one. I justified my reasons in OP:
> > > > 
> > > > - Keep as is, possibly amending DESCR.
> > > > - Remove.
> > > > - Merge into main, that is remove subpackaging.
> > > > 
> > > > Thanks for additional tips and instructions. I understood them
> > > > all
> > > > and
> > > > will incorporate them into my next revision as soon as we decide
> > > > the
> > > > fate of this subpackage.
> > > > 
> > > > On Wed, 2026-07-08 at 11:31 +0100, Stuart Henderson wrote:
> > > > > On 2026/07/07 21:28, Igor Zornik wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > Thanks for looking into it. As for the comments:
> > > > > > 
> > > > > > > Any reason to name the port go-chroma instead of just
> > > > > > > chroma?
> > > > > > 
> > > > > > There's already a chroma port. It's mentioned in the
> > > > > > Makefile.
> > > > > > I'm
> > > > > > open
> > > > > > for accepting a better solution to resolve naming conflicts.
> > > > > 
> > > > > It's called "chroma-syntax-highlighter" on repology and
> > > > > freebsd. A
> > > > > bit
> > > > > of a mouthful, but I think it's helpful to use an existing
> > > > > name if
> > > > > there is one.
> > > > > 
> > > > > If including chromad, I'd only rename the "chroma" binary and
> > > > > leave
> > > > > "chromad" as-is, as there's no conflict for that one. Or skip
> > > > > renaming
> > > > > and just let them conflict..
> > > > > 
> > > > > I'd rename the binary to something that works with
> > > > > "chroma<tab>"
> > > > > if
> > > > > renaming (chroma-hl?).
> > > > > 
> > > > > > > Is the -web subpackage really useful?
> > > > > > 
> > > > > > Well, no. As I've already written in my opening post, it
> > > > > > seems
> > > > > > it
> > > > > > serves
> > > > > > mostly for demonstrative purposes and it looks nice so I've
> > > > > > added it
> > > > > > anyway as an option. That's my personal take on it. I can
> > > > > > modify
> > > > > > DESCR
> > > > > > based on further decisions.
> > > > > 
> > > > > I don't see a reason to split them out to a subpackage;
> > > > > include
> > > > > the
> > > > > files in the main package if they're useful, or drop them if
> > > > > not.
> > > > > 
> > > > > > > Anyway is there an issue with tgz? It doesn't seem to
> > > > > > > build
> > > > > > > here:
> > > > > > 
> > > > > > Sorry to hear that. I don't know what could've gone wrong.
> > > > > > It
> > > > > > looks
> > > > > > OK
> > > > > > to me. I've prepared another .tgz with the port updated to
> > > > > > 2.27
> > > > > > as
> > > > > > that
> > > > > > was released in the meantime. 'make install-all' works on
> > > > > > today's
> > > > > > amd64
> > > > > > snap. I've also replaced tab with a space in WANTLIB.
> > > > > > Hopefully
> > > > > > you'll
> > > > > > have better experience with this version.
> > > > > 
> > > > > builds ok here. (I didn't try the older one). does also need
> > > > > NO_TEST=Yes.
> > > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
>