4 ms·

I use sourcehut for a few projects, and I love the build system. I don't have extensive experience with build systems, but I've explored a handful. What I lov

I use sourcehut for a few projects, and I love the build system. I don't have extensive experience with build systems, but I've explored a handful. What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. As a result, there's also not much about it to learn. Most of it uses my existing knowledge of Linux and surrounding tools. The git-by-email setup is more inconvenient. I haven't found an email setup I'm comfortable with. I also haven't tried a lot, but with a pull request system like github there's not really anything to try. Overall quite happy with sourcehut for my needs.

mariusor 4y ago
> The git-by-email setup is more inconvenient. Due to the distributed nature of git, that's not actually required. Any sourcehut project can merge branches that exist in different places on the Internet. The feedback and reviewing process might be more cumbersome, but accepting code contributions is not impeded in any way.
- vnorilo 4y ago
  Indeed. A pull request is indeed a ... request to pull changes! One fetch/apply later you can use your local merge tools to evaluate. I guess the various hubs, labs and buckets make it slightly harder to run malicious code on your own box, but the difference might be smaller than one would think.
  - _ikke_ 4y ago
    The issue is most users do not have the infrastructure to let others pull directly from their repositories, hence centralized hosts became popular.
    - mariusor 4y ago
      I think that at least for this specific use case the would be PostmarketOS contributors have access to Gitlab. Of course I can't speak for the devs of PostmarketOS, but on my own projects hosted on Sourcehut, that's how I ask for alternative contributions coming from people uncomfortable with sending patches using email.
    - GoblinSlayer 4y ago
      The idea is that centralized host doesn't imply centralized development model. You already have five centralized hosts for that matter.
    - cxr 4y ago
      Well, no, that's putting the cart before the horse. Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden. * And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.
      - Jasper_ 4y ago
        What are you talking about? git request-pull came far before GitHub existed, and that sends an email for a request & instructions to pull from a remote branch.
        cxr 4y ago
        I'm responding to the claim that GitHub solved the problem of everyone needing "infrastructure to let others pull directly from their repositories". What are you talking about? (The general tone suggests that you're refuting something about my comment. What part are you trying to refute?)
      - twic 4y ago
        It is truly weird to me that the standard workflow for submitting a change to someone's project is now to make a copy of their project, change it, and then ask them to import your change. This is inside-out and upside-down! Surely it would be a million times more intuitive for forges to offer a "submit a patch to this project" feature?
Arnavion 4y ago
>What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. FWIW, it's possible to do it for GitHub etc as well. These CI providers try to get you to use their bespoke "Actions", ie custom DSLs that only work with the one CI provider, but nothing prevents you from ignoring all that and just writing an "exec this shell script" step. It's what I do for all my GitHub repos. I can run the script locally just like the GitHub CI does it in its VMs.
- tjoff 4y ago
  It really is the way to do it. Then you are also version-controlling your build-setup and if the cloud or your self-host solution is down at the wrong time you can instantly run an equivalent build locally. The cloud is really about one thing and one thing only. Vendor lock-in. I don't accept that. And I don't see any sensible reason for it.
- Winsaucerer 4y ago
  That's good to know. Github actions is one of the (many) systems I haven't played with yet.

mariusor 4y ago

> The git-by-email setup is more inconvenient. Due to the distributed nature of git, that's not actually required. Any sourcehut project can merge branches that exist in different places on the Internet. The feedback and reviewing process might be more cumbersome, but accepting code contributions is not impeded in any way.

vnorilo 4y ago
Indeed. A pull request is indeed a ... request to pull changes! One fetch/apply later you can use your local merge tools to evaluate. I guess the various hubs, labs and buckets make it slightly harder to run malicious code on your own box, but the difference might be smaller than one would think.
- _ikke_ 4y ago
  The issue is most users do not have the infrastructure to let others pull directly from their repositories, hence centralized hosts became popular.
  - mariusor 4y ago
    I think that at least for this specific use case the would be PostmarketOS contributors have access to Gitlab. Of course I can't speak for the devs of PostmarketOS, but on my own projects hosted on Sourcehut, that's how I ask for alternative contributions coming from people uncomfortable with sending patches using email.
  - GoblinSlayer 4y ago
    The idea is that centralized host doesn't imply centralized development model. You already have five centralized hosts for that matter.
  - cxr 4y ago
    Well, no, that's putting the cart before the horse. Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden. * And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.
    - Jasper_ 4y ago
      What are you talking about? git request-pull came far before GitHub existed, and that sends an email for a request & instructions to pull from a remote branch.
      - cxr 4y ago
        I'm responding to the claim that GitHub solved the problem of everyone needing "infrastructure to let others pull directly from their repositories". What are you talking about? (The general tone suggests that you're refuting something about my comment. What part are you trying to refute?)
    - twic 4y ago
      It is truly weird to me that the standard workflow for submitting a change to someone's project is now to make a copy of their project, change it, and then ask them to import your change. This is inside-out and upside-down! Surely it would be a million times more intuitive for forges to offer a "submit a patch to this project" feature?

Arnavion 4y ago

>What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. FWIW, it's possible to do it for GitHub etc as well. These CI providers try to get you to use their bespoke "Actions", ie custom DSLs that only work with the one CI provider, but nothing prevents you from ignoring all that and just writing an "exec this shell script" step. It's what I do for all my GitHub repos. I can run the script locally just like the GitHub CI does it in its VMs.

tjoff 4y ago
It really is the way to do it. Then you are also version-controlling your build-setup and if the cloud or your self-host solution is down at the wrong time you can instantly run an equivalent build locally. The cloud is really about one thing and one thing only. Vendor lock-in. I don't accept that. And I don't see any sensible reason for it.
Winsaucerer 4y ago
That's good to know. Github actions is one of the (many) systems I haven't played with yet.