6 ms·

Designing a package manager from the ground up

76 points by fro0116 8y ago

iceninenines 8y ago
Not another vendor-lock-in package manager. And, very predictably, no end-to-end integrity and nonrepudiation. smh.
- peterwwillis 8y ago
  Yeah, it's unfortunate. Rather than a solution that could be adopted outside of CCI, this is only useful in those configs. So as soon as you use them in your org with this product, you have to reinvent the wheel to get the same functionality in any other CI that a different team might be using.
- fwip 8y ago
  Which package manager do you feel gets it right?
  - jf 8y ago
    I’m not the OP but Nix/NixOS is the closest I’ve ever seen to a “Platonic ideal” package manager
  - rkeene2 8y ago
    I think you'll like AppFS http://AppFS.rkeene.org/ http://AppFS.rkeene.org/
bluejekyll 8y ago
> Orbs have a domain-specific language (DSL) defined in YAML syntax that expresses the semantics of our build configuration. Am I the only one who finds YAML to be difficult to reason about? I find that if the config is that complex, JSON or XML to be much easier to deal with. I think of TOML as the best balance between ease of use and expressiveness. These ORBs sound similar to docker images, I’m surprised they didn’t offer a comparison, like “why not docker?”, or did I miss it?
- sirn 8y ago
  Orb is actually a Docker image (executor) plus few defined commands. Say, if you want to build a custom Slack notification for multiple projects, you'd create an Orb with an executor and a command, e.g. executors: alpine: docker: - image: alpine:3.6 parameters: webhook_url: description: URL to Slack webhook type: string message: description: Message to post to Slack type: string commands: notify: description: "Notify Slack" executor: alpine steps: - run: name: Notify Slack command: | curl -X POST -H 'Content-Type: application/json' --data "{ \ \"attachments\": [ \ { \ \"fallback\": \"<<parameters.message>>\", \ \"text\": \"<<parameters.message>>\", \ \"mrkdwn\": true, \ \"color\": \"#1cbf43\", \ } \ ] \ }" <<parameters.webhook_url>> So if I publish this Orb as say sirn/slack@dev, anyone can use this Orb in their build pipeline with: orbs: slack_notify: sirn/slack@dev workflow: foo: jobs: - slack/notify: webhook_url: "..." message: "..." I've been using Orb for the past month and I see Orb as a more of a way to share common steps definition (à la Ansible Galaxy) than something of Apt/Brew/NixPkg caliber. It's convenient in CircleCI's context, and easier to get started than trying to build a shared Jenkins Pipeline Scripts, but it's still weird that we're programming in YAML leveraging shell scripts instead of going directly to shell script (which is part of why I love builds.sr.ht).
  - peterwwillis 8y ago
    Man, that's terrible. How the hell are you supposed to syntax check that, or version control it, or collaborate on it? Extract it from yaml, do a thing, test it, then put it back in yaml, then run it and test it again? And if anyone else wants to make a change to your change, they now have to do the same? What a pain in the ass. If this is all Docker containers anyway, why aren't they just creating Docker images and referencing them? They're just shoving a Dockerfile into YAML, without the benefit of it actually being a Dockerfile.
- pjmlp 8y ago
oblio 8y ago
I really like their "volatile" decision. More package managers need to adopt it, in my opinion.

76 points by fro0116 8y ago

iceninenines 8y ago

Not another vendor-lock-in package manager. And, very predictably, no end-to-end integrity and nonrepudiation. smh.

peterwwillis 8y ago
Yeah, it's unfortunate. Rather than a solution that could be adopted outside of CCI, this is only useful in those configs. So as soon as you use them in your org with this product, you have to reinvent the wheel to get the same functionality in any other CI that a different team might be using.
fwip 8y ago
Which package manager do you feel gets it right?
- jf 8y ago
  I’m not the OP but Nix/NixOS is the closest I’ve ever seen to a “Platonic ideal” package manager
- rkeene2 8y ago
  I think you'll like AppFS http://AppFS.rkeene.org/ http://AppFS.rkeene.org/

bluejekyll 8y ago

> Orbs have a domain-specific language (DSL) defined in YAML syntax that expresses the semantics of our build configuration. Am I the only one who finds YAML to be difficult to reason about? I find that if the config is that complex, JSON or XML to be much easier to deal with. I think of TOML as the best balance between ease of use and expressiveness. These ORBs sound similar to docker images, I’m surprised they didn’t offer a comparison, like “why not docker?”, or did I miss it?

sirn 8y ago
Orb is actually a Docker image (executor) plus few defined commands. Say, if you want to build a custom Slack notification for multiple projects, you'd create an Orb with an executor and a command, e.g. executors: alpine: docker: - image: alpine:3.6 parameters: webhook_url: description: URL to Slack webhook type: string message: description: Message to post to Slack type: string commands: notify: description: "Notify Slack" executor: alpine steps: - run: name: Notify Slack command: | curl -X POST -H 'Content-Type: application/json' --data "{ \ \"attachments\": [ \ { \ \"fallback\": \"<<parameters.message>>\", \ \"text\": \"<<parameters.message>>\", \ \"mrkdwn\": true, \ \"color\": \"#1cbf43\", \ } \ ] \ }" <<parameters.webhook_url>> So if I publish this Orb as say sirn/slack@dev, anyone can use this Orb in their build pipeline with: orbs: slack_notify: sirn/slack@dev workflow: foo: jobs: - slack/notify: webhook_url: "..." message: "..." I've been using Orb for the past month and I see Orb as a more of a way to share common steps definition (à la Ansible Galaxy) than something of Apt/Brew/NixPkg caliber. It's convenient in CircleCI's context, and easier to get started than trying to build a shared Jenkins Pipeline Scripts, but it's still weird that we're programming in YAML leveraging shell scripts instead of going directly to shell script (which is part of why I love builds.sr.ht).
- peterwwillis 8y ago
  Man, that's terrible. How the hell are you supposed to syntax check that, or version control it, or collaborate on it? Extract it from yaml, do a thing, test it, then put it back in yaml, then run it and test it again? And if anyone else wants to make a change to your change, they now have to do the same? What a pain in the ass. If this is all Docker containers anyway, why aren't they just creating Docker images and referencing them? They're just shoving a Dockerfile into YAML, without the benefit of it actually being a Dockerfile.
pjmlp 8y ago

oblio 8y ago

I really like their "volatile" decision. More package managers need to adopt it, in my opinion.