I'm reading it the same way. I'd be very

[dusk wasp]

Yes, I was surprised and confused too about this default behaviour when I saw my module in the Daggerverse without having published it myself (this happened as a result of calling my module with dagger call -m I think).

IMHO it feels weird having not-ready modules polluting the Daggerverse. I guess this will change once private modules are supported.

[high ravine]

No matter what, putting modules into the Daggerverse must be an opt-in process IMHO.

[steady fulcrum]

\cc @gleaming prism

[old moss]

Agree 100%

[bronze acorn]

Thanks for the feedback. One problem is that dev branches are published at the same level as tagged releases, which results in "not ready" modules being published. We're going to fix that. And of course none of this will apply to private repositories.

That said, for tagged releases we plan on continuing to auto-publish, the same way Go modules do it (we've copied a lot of the Go ecosystem's features).

We'll focus on fixing the "dev branches look like tags" problem, then reassess how the experience feels, and see if we need to make any further changes. Wdyt?

[high ravine]

@bronze acorn - What is the use case or user story that entails a requirement or wish to automatically publish a module to Daggerverse?

Is there maybe a chance to add a flag in dagger.json to either opt in or keep the current state, but add an opt out of the automatic publishing and to then have a --publish | -p flag in dagger call?

I fear we'll basically be getting more and more junk and duplicates and a mess of crap in the end in Daggerverse without this too.

It's pretty messy there as it is already, tbh.

[bronze acorn]

Tagging a release is a pretty deliberate step, it adds friction and communicates intent. So making that a stronger filter for publishing on daggerverse will help with the noise. Let's give that improvement a chance before over rotating

[high ravine]

Is tagging a release a Go practice?

[bronze acorn]

I believe it's a pretty universal open source practice but yes, definitely an established Go practice as well

[high ravine]

I guess I'm confused a bit. For instance, with JavaScript. a dev tags a release via the npm package manager, and it only happens with the publish command.

[bronze acorn]

It's just a better publishing and consumption experience. In a source-first ecosystem where you don't actually need to publish artifacts to a separate registry (unlike npm or docker hub), it's very convenient for the search index to just find what you already published on git.

For consumers it simply means more content on the index.

[high ravine]

Let me look into what tagging/ publishing process entails in Go. Be right back.

(yeah, I'm just getting Going with Go) haha.. pun intended.

[high ravine]

Ok. So release tagging in Go is just the git action of tagging a commit (usually as a release). That is pretty simple. I'm still not convinced it is a good idea to feed all "released" modules into Daggerverse. I think it should be a conscious decision to share one's work. My last 2 cents.

[bronze acorn]

It used to be that way but it was not a great experience. Once you get the hang of source-first, and realize that a git tag is all you need to release... It quickly becomes redundant to go publish each new tag, to what is basically just a search engine. It's way more convenient if the search engine finds new content for you.

If you think of Daggerverse as a search engine, it helps. Your module will pop up in Github search right away, after all. Why not in Daggerverse search?

[rugged wren]

I am interested in how the private repos will affect this. Suppose I want to write a dagger build pipeline for my own home automation, hosted in a git repo within my own home network, I am guessing since it isn't on github.com, it won't show up in the index. Is that what is meant by private (i.e. not hosted on GitHub.com)? Or does it use some other kinds of differentiator?

[bronze acorn]

If it's publicly accessible, it will be crawled and indexed like the rest, regardless of domain *

Conversely it's a private git server, it won't be crawled or indexed, regardless of domain *

* at the moment daggerverse only supports github, but we will fix that soon.

[rugged wren]

Gotcha. I think something like that will probably get flagged by our company's cybersecurity review (sending internal network information out to an unapproved cloud service), so I am with @high ravine in that it'd would be great if we can have at the minimum an opt-out option.

(A bit about my use case: I work in a restricted environment and want to introduce Dagger to replace a bunch of old Jenkins pipelines. Since Dagger is a new tool we have to go through a bunch of reviews to get this approved and I am looking for all the gotchas that may come my way)

[bronze acorn]

An opt-out is a perfectly reasonable request 👍 I suspect most organizations that don't tolerate devtools sending telemetry, already have corporate proxies locking all traffic down. This currently breaks dagger for other reasons (auto-download of engine container & sdk material) but probably also cuts off daggerverse analytics. Note that this doesn't guarantee your open-access modules won't be crawled. For that guarantee you'll need to not make the repo public in the first place.

[high ravine]

Ok. I can see the search index parallels. Though, if I want Google to find my site's content properly, I can offer Google or other search engines a sitemap. And, if I don't want search engines to spider my content, I can opt-out of my site being crawled with a robot.txt file. I'm still in control.

An opt-out is a perfectly reasonable request 👍

That was my minimum wish too. Cool! 👍🏻

For that guarantee you'll need to not make the repo public in the first place.

If we can opt-out, it should also count for any scraping too.

Please. 🙏🏻

[bronze acorn]

Yes the upload-sitemap analogy is a good one, exactly why we left an explicit "publish" button on daggerverse so you can explicitly publish if you prefer (for example if your workflow needs assurance that the publish is done)

[high ravine]

To me, Daggerverse should be similar to Jenkins plugins. A highly curated resource and not a messy search index. 🤷🏻‍♂️ 😊

[high ravine]

And, I promise not to bother you again with this.

[bronze acorn]

We will definitely add layers of curation. Among other things, we would like to start a standard library, with quality and stability guarantees, that grows over time