#Terminology 🚲🏠

1 messages · Page 1 of 1 (latest)

north heron
#

Moving to a thread 🙂

north heron
#

I am trying to reconcile 2 different constraints with this terminology work:

  1. Our words (and our meaning for them) should fit well with our user's words (and their meaning for them). It should all reinforce our explanation of what Dagger is for and how it fits with their existing way of working.

  2. Our words (and our meaning for them) should fit well with the technical understanding of how Dagger works, in the way that we want users to understand them.

#

For 1, I'm curious about your thoughts @bright sorrel @swift crow : as Zenith users, are you comfortable saying that your Zenith environment is your dev environment?

#

With sentences like:

  • I daggerized my entire dev environment, here it is if you want to try
  • Thanks to Dagger/Zenith, all my CI logic is embedded in the dev environment. "CI" is just a feature of development.
  • Want to contribute to our project? Just install Dagger, load our standardized dev environment, and you're ready to go!
#

OR, another option, would you rather say Zenith gives you a CI environment that can run alongside your (regular, non-daggerized) dev environment

bright sorrel
# north heron With sentences like: - I daggerized my entire dev environment, here it is if yo...

Doing my very best to roleplay having no pre-existing knowledge of Zenith:

are you comfortable saying that your Zenith environment is your dev environment?
No, that wouldn't make immediate sense. My "dev environment" is a combination of where I write code and the tools I need to test/run/etc.

It's a subtle difference, but I would think of Zenith as a component of my dev environment. That is unless I execute my whole dev environment inside a Zenith shell; that's when it would feel intuitive to say "Zenith is my dev environment".

Otherwise, saying "Zenith is my dev environment" would be like saying "Make is my dev environment". Even if every command for my whole development workflow I run is defined in a Makefile, I would never say Make is my dev environment.

I'm thinking of that example specifically because there was at least one user we demo'd to who brought up how Zenith feels like a much more powerful Make (and possibly multiple users we demo'd too, can't remember for sure rn). And while that's not a 100% perfect one-to-one comparison, it's fairly apt just in that they are both DAG execution engines that incorporate caching.

#

To be clear, I can see people adapting to the new terminology and saying that Zenith is their development environment, but I do feel like it takes a bit of a conceptual hurdle to get over at first. At least from my perspective

bright sorrel
bright sorrel
#

Thinking about this again this morning, I do still think there's a good argument for "Extension" as the terminology, all the abstract nonsense aside.

The idea being that Dagger is (in its full fruition) the ultimate modular system for defining+building+distributing+running your dev environments. The subtle difference being that it isn't your dev environment, it's how you build your dev environment, how you run your dev environment and how you share it with others.

"Modular" being the key word there. Extensions are "mods" to dagger that enhance it with new functionality (someone brought that up recently). Honestly, we could even consider the term "Mod" instead of "Extension" 🙂 It sounds sort of cool, but has the downside of conjuring memories of me trying to install game mods as a kid and completely destroying them (might just be me, I don't know)

Going back to your sentences, I think they make sense w/ extension:

  • I daggerized my entire dev environment, here's my extension if you want to try
  • Thanks to Dagger/Zenith, all my CI logic is embedded in the dev environment. "CI" is just a feature of development.
    • I actually don't think this needs to change at all. Still makes perfect sense even if we replace Environment w/ Extension
  • Want to contribute to our project? Just install Dagger, load our extension, and you're ready to go!
#

Maybe one of the biggest downsides of "Extension" vs "Environment" is just that "Extension" sounds very boring and straightforward, whereas "Environment" feels more rich and full of possibilities. But sometimes when it comes to naming boring can be better, it depends obviously

stuck sphinx
#

If you want an outsider's perspective.

Within my company we use the term "environment" to mean an environment (i don't know how else to describe it) that we deploy applications to. Like DEV, QA and PROD are managed environments. There may also be ephemeral environments that you spin up and destroy to test an app.

In my SDK/CLI I use the term to mean "config". An Environment is a set of configs you pass around the app. All a build needs to run should be available in the environment.

Neither of the above fit the zenith "environment" definition as far as I can tell. There may be other interpretations of what an Environment is within other companies or projects. I think the term Extensions has less such conflict.

north heron
#

@stuck sphinx I think the use of "environment" in this context would be closest to how projects like Devbox, Devpod, or Nix talk about "dev environments"

#

Usually they mean it as one container, with all the dependencies needed to build, test and run the software you're developing

#

Devbox landing page: https://www.jetpack.io/devbox

Portable, Isolated Dev Environments on any Machine
Devbox creates isolated, reproducible development environments that run anywhere. No Docker containers or Nix lang required

Devbox: Portable, Isolated Dev Environments

Devbox creates isolated, reproducible development environments that can run anywhere without Docker or virtual machines.

#

Devpod: https://devpod.sh/docs/what-is-devpod

DevPod is a tool used to create reproducible developer environments. Each developer environment runs in a separate container and is specified through a devcontainer.json

What is DevPod? | DevPod docs | DevContainers everywhere

DevPod is a tool used to create reproducible developer environments. Each developer environment runs in a separate container and is specified through a devcontainer.json. DevPod providers can create these containers on the local computer, any reachable remote machine, or in a public or private cloud. It's also possible to extend DevPod and write...

#

@stuck sphinx there are definitely to competing/overlapping uses of the term "environment" in the current state of the art: one that is deployment-centric, as you described it. WIth a big focus these days on ephemeral/on-demand environments. Often kubernetes-backed, but not always. Usually infrastructure and prod-centric, even when they aren't actually prod environments. In other words, this term is usually used by infra teams striving to bring their infra closer to the devs

#

The other use of the term is the one I described above. "Dev environments", generally in the context of software dependencies installed on a single machine. Possibly inside a container, or at most a docker-compose project. In this use of the term, the prod infra is not the starting point, but a separate entity that may or may know about or have access to.

stuck sphinx
#

Hey @north heron , I understood your points and I agree on the two popular usages of the term environment. However, I didn't get your conclusion. Are you saying environments are still better suited for Zenith? I am not sure if Extensions are ideal in the grand scheme of things but from my point of view, it will be much easier to explain the features of zenith as extensions than environments to my peers. But that could be because of a lack of understanding on my part too 🙂

north heron
#

“environment” is still a viable candidate yes. We need a word that captures what’s the repeatable, scriptable, composable thing that can contain all the artifacts, checks, services, CLIs and interactive shells you need to develop your software project, along with all the pipelines needed under the hood

#

“environment” is not the only word for that but it’s pretty good

#

“extension” cannot play that role, because you still need a word to designate what you are extending.

For example VScode has extensions, to extend your workspace.

#

In the current prototype, you create environments, then add extensions to add capabilities to your environment

bright sorrel
north heron
#

I think that is a viable option too (would have to think through the UX implications a bit more). But still, we wouldn't escape a word emerging to designate the "thing" you are Daggerizing, that you can artifacts for, etc. If we choose not to define one in the product (definitely an option, it's the current status quo after all), something like "project" is sure to emerge. See https://github.com/dagger/dagger/issues/4414 for example - the word "project" I keep using was being used left and right at the time.

GitHub
Standardize project entrypoint · Issue #4414 · dagger/dagger

Problem TLDR: Dagger does not define a standard interface for project entrypoints, which limits what it can do for users. Dagger works by writing an entrypoint for your project: custom software tha...

#

In other words, even if we say "extensions are a way to extend Dagger", users would complete the sentence with "... in the context of my <X>"

bright sorrel
# north heron I think that is a viable option too (would have to think through the UX implicat...

Oh okay, I see what you’re saying I think, but I guess my immediate reaction is that <X> could and hopefully should be many different things, people should daggerize their projects, their monorepos, their CI, their build system, their test framework, their dev environment, etc. I almost feel like having a set word there would be too limiting, people should be able to fill it in with whatever word they are comfortable with and makes sense in their context.

You could almost imagine a landing page that says “Daggerize your …” and then cycles through different words, with links to examples of daggerizing different things. (Not an actual suggestion, I am not to be trusted with frontend design 😁 but just popped into my head)

north heron
#

yeah that is an option as well. If we think there are many things that can be daggerized, we would still benefit from a word to describe any daggerized thing. I think there are pros and cons to that approach.

  • pro: low opinion. doesn’t challenge anyone’s use of any word, basically
  • con: with low opinion can come low clarity. “what exactly do I daggerize?” “so many things, where do we begin”
#

also all the things you listed all seem pretty closely related, it feels doable to reduce it to a few simple words that express our opinion of how they should all work together

#

I would be very interested in your thoughts @split magnet from the MLops perspective... Sorry for dropping you into a mega-thread 🙂

jagged tundra
#

another external viewpoint, but someone who is somewhat familiar with what you are trying to achieve

I think "environment" is a very overloaded term in software. It can just mean too many different things and it's also kind of abstract. But I also feel like "extension" is too abstract of a term for someone unfamiliar with Dagger. I am just going to throw some other words out there with no other context to see if they stick. In no particular order:

  1. Workspace
  2. Toolkit
  3. DevSuite
  4. CodebaseKit (CBK)
  5. DevRig
  6. DevHub
  7. PipelineSuite
north heron
#

Since we were discussing terminology @torpid heart ...

torpid heart
#

Don't involve me in the most difficult part of software "Naming things" 🙂

north heron
#

Can I interest you in a thread about caching invalidation then? 😛

#

Also a popular topic around here actually

torpid heart
#

You 100% can. On this Ninja describes itself as a "Build System", this is pretty apt, as you build local or on CI, but the release step is the next level. So is it "Build and Release", but, does "Build" cover "Test", which Dagger enables, so are we now at "Build, Test, and Release"

#

So thinking about this, I am thinking "Deploy" is more appropriate than "Release". "Deploy" being the act of throwing an artifact at the Runtime, "Release" being the act of allowing the end user to use the deployed application.

#

Theoretically Dagger could cover all of these use cases

#

If you adopt that kind of Terminology, "Build, Test, Deploy, Release" then you could structure extensions and the workflow around those concepts.

#

But...

#

We also discussed "Develop" the other day, and the capability for Dagger to provide its build container as a DevContainer standard. Now you have...

#

"Develop, Build, Test, Deploy, and Release"

north heron
#

Here are the different possible ways to describe Dagger, that I remember from our conversation:

  • a build tool
  • a CI tool
  • a tool that replaces your Makefile
  • a tool to make reproduceable dev environments
torpid heart
#

So are you at... "Dagger is a tool that allows you to codify and standardize your Develop, Build, test, Deploy and Release lifecycle. It enables collaboration and code reuse across all roles in your application delivery process"

#

Copywriting after my first coffee of the morning is not my strong point

north heron
#

Is the copy better before the coffee? 🙂

#

This is very helpful btw, I appreciate you sharing your raw thoughts

torpid heart
#

Hahah, I think you need that flow state of just enough, not too much coffee

north heron
#

Here's one possible synopsis that I like. It borrows snippets from various ideas contributed by various people.

Dagger is a universal, cross-language scripting tool for modern software projects. Dagger integrates with your project's build, test and deployment tools, and gives you an API and SDKs to compose them into powerful pipelines. <somethign about cross-language composition>

stuck sphinx
#

I like it. Is "scripting" the right word though? How bout "programming"? As Dagger allows the use of full programming languages and can do much more than just scripting.

swift crow
north heron
#

Yeah I used to always say programmable, but “scriptable” seems to resonate more so I eventually changed my choice of words

north heron
#

How does everyone feel about this API schema draft:

extend type Query {
  "Initialize an environment. If no initial configuration  is provided, the environment will be blank"
  environment(configuration:Artifact): Environment!

  "Search the Daggerverse for reusable configurations"
  daggerverse: Daggerverse!
}

"A scope for Dagger operations"
type Environment {
  "Load an extension into the environment"
  withExtension(extension: Artifact!): Environment!

  "Load a mod into the environment"
  withMod(mod: Artifact!)

  "Set the environment's context directory"
  withContext(workdir: Directory!): Environment!

  // all entrypoints go here
}

"The Daggerverse is the official gateway to the Dagger ecosystem, and all the Dagger-compatible content it has offer."
type Daggerverse {
  """
  Search the Daggerverse for reusable configurations.
  """
  configurations(
   keywords: [String!]!,

   "Include mods in the search"
   mods: Boolean=true): [Artifact!]!

  extensions(keywords: [String!]!): [Artifact!]!
}
#

cc @raven tiger for the daggerverse part 🙂

#

cc @bright sorrel @swift crow for the bikeshedding 😛

swift crow
#

Raises a lot of questions for me:

  1. What's a mod vs. an extension?
  2. What's a configuration? For me it'll be very hard to separate "configuration" from something declarative/config-file-shaped, fwiw; if it's meant to be something more abstract, I'm not keen on it
north heron
#

A Dagger configuration is literally that: a bunch of files that you point the CLI at, that will cause it to behave a certain way. We could call it "project" or "workspace", but I've heard the word "configuration" used a few times in the context of CI, so it feels like the most familiar and generic

#

In our case those files happen to be mostly code ( plus dagger.json etc). But I think it still holds. It's an awesome / powerful / scriptable configuration. But still a configuration.

#

"Welcome to our open-source project! We've packaged our dev environment as a Dagger configuration, to make it easier to get started. Start by installing the Dagger CLI, then load the following configuration: ..."

swift crow
#

Ehh, I get the angle and you could even argue "configuration as code" but I don't find it intuitive

#

This is the same thing you previously called "controller" right?

north heron
#

Yes

#

I feels right to me for the same reason "scriptable" seems to resonate better than "programmable"

#

Re: "mod": that's less core and maybe I should have left it out. But @bright sorrel brought it up recently and I think it does fill a gap. But you can safely ignore it to keep the scope of discussion manageable

#

@swift crow setting aside the exact choice of word. How do you feel about having "environment" to mean the runtime construct, and another word for the artifact that you use to configure it?

#

To me it felt like it helped make each word feel less overloaded

swift crow
#

What if we called it (controller/configuration) "entrypoint," rather than describing each env.WithFoo as an entrypoint? It gets built into a single /entrypoint executable and configured as the entrypoint already, but I think even aside from that technical detail it kind of makes sense

swift crow
north heron
#

I think it's too in the weeds. Like extension, it needs to qualify something else. "Entrypoint to what? In the context of doing what?" You know

#

Also: "like a Docker entrypoint?"

swift crow
#

Various routing-related terms swimming through my head atm: handler, router, controller (dun dun dunnn)

#

Would be nice to have a mind-map/graph of each user-facing concept with strawman names but precise descriptions, so we can play with all the terminology from a bird's eye view. I suppose GraphQL schemas are close to that already

#

I remember mermaid.js being pretty decent for that

north heron
#

I know Helder is a mindmap expert 🙂

#

My pitch for now: let's try "configuration" as a generic placeholder for now, while we keep looking for more specialized and thematic alternatives? It would give us immediate relief to 2 pains:

pain 1: "Environment is super overloaded and you guys are confusing me"
pain 2: "You're using the same word for a runtime construct, and a set of config files and scripts, which is confusing me"

swift crow
#

Yeah my skepticism is nonblocking, it might grow on me, it's at least nice that it includes 'dagger.json', and if you squint you can say that's really what "configuration" refers to, and the code that it sits alongside is just a dependency of it 😛

#

curious what others think too

north heron
#

"Daggerfile" 🙂

#

The README that started environment-mania

north heron
#

@swift crow I'm exploring a variation where "configuration" is more focused on the dagger.json config file itself (and everything with code in it is an extension)

swift crow
#

Ooh interesting

north heron
#

(based on your feedback)

#

it's actually feeling a little like full circle to the very first versions of cloak... Which had downsides also. I'll try to document the tradeoffs as I go

swift crow
#

Random thought: "environment" => "distribution" / "distro"? It's kind of similar, but with a less strict definition, and the current predominant meaning ("flavor" of Linux OS) is vaguely similar, in the sense that they're kind of like "flavors" of the Dagger OS. Also conveys the notion that it's something packaged & delivered.

north heron
stuck sphinx
#

you get a dagger distro, and you get a dagger distro and everybody gets a dagger distro... I don't dislike the sound of that.

swift crow
#

@bright sorrel @north heron just realized one risk with "module" is that some languages might reserve it as a keyword. I just tried Ruby, Python, and JS though and they all let you define a function named "module" so maybe it's not that bad.