As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like
I wasn't trying to relate anything to the bigger conversation, I just meant to draw attention to the fact that GitHub is not golang's package manager
That said, I would guess the 'bigger conversation' is that it is much harder to tpyo <<import "github.com/DataaDog/datadog-api-client-go/v2/api/datadogV2">> than $(npm i dataadog) or similar in a "flat" package namespace (same for its $(uv pip install dataadog) friend)
None of those cited ones fix the dependency lineage issue, proving that release 1.1 was authored by the same chain of custody as release 1.0 of any given package. One can opt in to gpg verified dependencies in Maven, but it is opt-in. The .jar artifacts can also be cryptographically signed, but the risk that's trying to drive down is tamperproofing and not lineage, AFAIK
Good catch — thanks for digging into that. You’re right: the domain still has a mix of A records (AWS + GitHub Pages), which explains why some people see different results.
I have removed the broken A records and the site works normally now. Appreciate the pointers and links
In dagger.js interpolation is scoped to attributes and text nodes — anywhere you put ${…} inside the HTML markup, the expression is evaluated against the current directive scope.
In your sample code, winner is looked up from the nearest +load directive context. Interpolation isn’t “everywhere” JS-style, it’s only applied to the DOM text/attribute content that Dagger processes. Actually it's standard string template in JS.
You may also use the text directive instead to avoid using inline expression:
<div class="text" text="`${ winner ? 'Wins' : 'Draw' }!`">
</div>
I just realized that's an excellent opportunity for "reverse phishing:" you can mangle the first 4 digits of your card [or make one up wholesale] and if they say "thank you, sir" you know they are fake. The real bank will spot that mistake instantly since that prefix is per financial institution
Two things: folks care about Brew because its update story is nice; otherwise one needs to constantly revisit your /releases (or plug /releases.atom into their RSS reader) in order to know. It also offers very light "I got what I expected" behavior via their use of sha256, which your current setup won't participate in since you're only publishing .md5 anyway
That leads to the second thing which is that you said you "added binaries" but your release artifacts are .tar.gz which means that one now needs to `curl -fSL | tar -xzf - -C /whatever` and deal with whatever interior directory scheme you are using (I didn't check)
I suspect I may be throwing good commentary after bad, but if you did want to participate in Brew distribution, but don't want to go through their stupid PR process, you can retain control over your update schedule by creating a "Brew Tap" and then the consumer would (e.g.) `brew tap plutov/brew && brew install plutov/brew/oq` which also gets away from the naming collision
I also love Homebrew and use it daily, at the same time I don't want to go through the review process, but tap sounds good, will try it out, maybe goreleaser supports that too?
Honestly whilst the docs make the review process sound complicated, I went through it a few months ago and it ended up being super simple. Just follow the instructions to create the new formulae PR (and look at other recent ones) and then you’re all done. Updates are handled by a bot they run automatically when you make a new GitHub release, so you don’t even need to interact with the homebrew repo after setup.
You do have a naming conflict though unfortunately so I’m not sure how you would deal with that.
It's possible the following argument is what you meant by "from the SQL syntax," and if so apologies for the noise
At least one demonstrable difference I can see between your recollection and this feature is that the column name being part of the DDL pushes the logic down into the DDL, versus every client having to carry that magic expression around with them. I think it's likely the age-old application-logic-client-side versus stored-proc camps
db=# select id, cast(length(name) AS text)||'0' as silly from my_table
as compared to <<select id, silly from my_table>> for the consumer
The virtual column feature I remember is halfway in between. It is not part of the DDL nor reported table schema, so the developer needs to know about it.
But if a function called silly with input type my_table existed, you could still do your second query. It has syntactic sugar for making a bare function name implicitly invoke on the current row record.
I can't remember if that sugar could also be used in an expression index. I never really used this syntactic feature, as I thought being more explicit with function calls would be better coding style.
