thoughtpolice
commented
1 year ago Honestly, the answer is basically "Whatever works best for you", because I really can't say. Please see #17 for some extra context. In short:
- Some reusability of this code would be nice, I agree
- But the API and design space is shifting a lot, right now, as I explore various features like remote execution, rule design, what should drive what, etc. Buck2 may also need to be changed as part of this.
- Because of that, I'm not really willing to separate the components too much because I'm doing most of the work
- The intent of this experimental repository is to form the basis of a build system for a future project of mine
- That's also part of the motivation for the installer: it's supposed to go along with your project too to clone "whatever" as a one-stop shop.
- This repository will also form the basis of other experiments too in the same vein; for example I may migrate some of the PR ideas from bors-tests into here.
- I'm not sure if the long-term future includes deprecating this repo and encouraging forks, continuing it separately, or something else
- There are technical tools we can use to help downstream consumption that aren't Git submodules
- Also, Git submodules are bad
- You're free to submit issues and especially PRs, if you can motivate them. I don't discourage this but be prepared to throw away lots of stuff, too.
As per the penultimate point I'm not going to force submodules on people, but if you can find some way to make that work for you, and pin this and occasionally update it, I'm OK with it as long as it doesn't incur something on me, really.
As noted in #17, I would eventually like to use a tool like Josh, Mononoke, or Eden to help separate these things. Josh is the most viable today since Mononoke and Eden are MIA and their capabilities are unknown in comparison.
Here's an approach I would happily endorse:
- Let's see if we can get a Josh
workspace.joshfile added somewhere, that would allow you to clone a "slice" of the repository including downstream-relevant build components. That can remove all the other stuff, and we can shuffle around what we need to. - Then, you can use Josh's
josh-filterto import that workspace into your downstream repo; namely it can create a git history in your own repository that makes it look like this code was always developed there. So you can have abuck/subdirectory in your repository that tracks this repository as a virtual workspace, and you can justgit pullfrom it to get updates.- Basically,
git subtreeon steroids.
- Basically,
- All upstream development happens here, and if I break something you can complain loudly or submit a PR.
This would be a very useful experiment in exploring Josh's viability and power, it's something I've been meaning to do for a while, since it can solve lots of sticky issues like this.
I also encourage you to submit PRs if you're getting value out of this repo and aren't shy about the work, I guess; I don't mind having extra things under src and if anything it would be good to have another set of eyes on the written rules. Please consider this repository a continued experiment, however; I'll be tinkering with it for a while I suspect, but I also have lots of other things to research and think about.
Fuuzetsu
So, this repo sets up buck + watchman + makes the rules prelude available. But it also just clones the whole repo wholesale, including examples, setup/update scripts etc.
So far I've ran the setup script and then I've been adding my own project stuff on top to
src, some tools intoolsand so on. But I probably don't want/need this whole repo and its history so I've been thinking that I should start to selectively delete the stuff that doesn't seem necessary for me. At the same time, once I want to update the rules or buck exprs, I need to update the relevant contents...What's the expected workflow? Should there be some separation between buck/prelude that users pull in and the rest of the repo? Should it be a submodule somehow maybe? I'm not sure.