Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it.
With that being said I have put a good amount of work into the QuickStart.
The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’d love to hear it.
As someone who has had to run and maintain build systems for several (sadly far too) large projects (5MLoc+), I want a product that sells me on how easy it is to create _correct_ builds, and how impossible it is to create incorrect ones.
So much wasted time goes into diagnosis of incorrect results from incremental builds that most people who implement CI systems never use incremental builds, and always build from scratch. Developers are far too used to having to do things like 'make clean' because their build didn't work quite right. Efficiencies are then gained by doing things like ccache/Gradle build cache, which trace their dependencies better than most naively written build systems do.
Unfortunately, reality is messier than this. For example, Please currently has escape hatches that can be used that nullify these guarantees. What I have found is that if such a mechanism exists it will eventually be abused.
My perspective here is specifically from that of a maintainer of large builds where the code base is always under active development. Murphy's law becomes your enemy at scale.
This is not a criticism of Please - just an observation that as an industry we are not there yet. But, I'm happy to see things moving in the right direction.
I haven't had many issues with non-determinism when using Bazel/Blaze? Especially when you use remote execution or sandboxing it's pretty hard to avoid being hermetic.
This is admittedly contrived, but sadly not unrealistic.
Again, I am not picking on Bazel here. Correct builds are difficult enough to get right even when everyone involved wants to keep the build correct! But, the reality is that a lot of real-world build conditions can be downright hostile. (did you know that ext4 vs xfs can change the order JARs in the same directory are loaded off the classpath? I wish I didn't!)
Yeah fair point. At Google a lot of these non-deterministic rules are either banned through "date" just not existing on remote execution machines, or through determinism tests that ensure rules behave. Maybe in real-life scenarios it's not as easy as I claim, as you suggest.
Agree with the OP. I went through both the Python and Go quickstarts. They were easy to follow, but I’m also not seeing the value proposition. The build system has different DSLs for different languages so I’m not seeing the advantage of switching from I.e. go install ./... for Go and setuptools for Python? No offense, but you didn’t answer the question: what’s it good for?
In that case, you can stitch both Python and Go builds together in the same interface, and then tie them into further actions (e.g. Docker builds, Kubernetes), again using the same interface. Neither setuptools nor go build are particularly helpful to that goal.
(I'm one of the original developers, but these days do less maintaining of it than tatskaari does)
My rubric for documentation is "how many clicks to code". I found the installation instructions, and started to look for usage, but didn't find it. Too many clicks. That's where I'd start.
PS - IMO the gold standard for this evaluation method is Sinatra.rb, which is zero clicks to code.
We wanted something like Blaze (Google's system); at the time we were using Buck which didn't satisfy us (e.g. only one output per genrule, no directories; and it was more or less impossible to write first-class support for a new language without modifying the core system). Subsequently Bazel got released but we still find that a bit lacking in some areas; e.g. the CLI, the JVM reliance and some of Starlark (e.g. it maintains Python 2 syntax compatibility so can't have type annotations).
We'd also tried Gradle previously but that was pretty awful for anything non-Java which made it a non-starter.
To be clear, I'm one of the original implementors, although I imagine that was obvious already...
For most purposes, Bazel dependency on Java is an implementation detail (users don't need to install a JVM), although you might notice it if you need to bootstrap Bazel.
(I co-designed Starlark and I used to work on Bazel)
I’m not sure if the feature was added after you started building Please but Buck does support multiple outputs from a genrule now. It’s kind of hacky though; you write a genrule that produces a directory containing said multiple outputs, and then you can write rules to extract the subcomponents. (I don’t know why I feel compelled to point this out. I worked on Buck for about a year, several years back. )
At first this wasn't a singular clear answer I was hoping for, but the many points being made here make it clear that it's a complex area and there's room for another advanced/high-perf build system to cover a broader range of usage.
You hopefully have tried out many other build systems by now, been frusted with all of them, and only then made your own. And with all that experience with the status quo, marketing should be easy.
If you haven't done that, this project is a net-negative on the world, because the proliferation of build systems exacerbates Conway's law and balkanizes our software commons.
I am not an author, but was around when we decided to create Please in 2015.
When we created Please we were currently using Buck from Facebook. As has been covered elsewhere at the time it had some limitations which meant that it was getting more and more expensive to workaround (no multiple outs from rules so doing things like sourcemaps was hard etc). We had previously migrated from a set of disparate build tools (Gradle, Gulp etc) to Buck after evaluating it against Pants (we actually trialled our repo with both).
We all had experience with Blaze (Bazel did not exist in 2014/2015) and wanted to get closer to the experience we had in Google, hence the final decision to build our own. At the time we rolled it out we had full Buck compatibility (and actually most of our engineers did not notice initially). Once we were happy it worked, we migrated in full to Please.
Overall it allowed us to provide much better tooling for our developers (queries on the build graph for smaller CI/CD footprints, coverage in all languages, and for rules that can output multiple languages (like protocol buffers) we only build variants in the requested languages rather than all languages).
If Bazel had been open-sourced and easy to extend at the time we would certainly have looked to adopt and improve it (as we did with Buck at the time). But by the time they open-sourced it the two system had diverged in their approach and use cases.
I (obviously somewhat biased) think having multiple principled build systems which prioritise the needs of different communities is good for the ecosystem overall (and allows the sharing of good ideas such as the Remote Execution Interface).
Marketing can be hard not because you don't have something worth marketing, but because marketing is a skill-set largely orthogonal to software development.
That's only true if you define software development in a pretty particular way.
For me, writing code is a way of solving problems for people. That involves listening to them to see how I can help. Then collaborating with them to iteratively make something that fits their needs. Which includes helping them adopt it and get productive with it. To me, all of that is part of software development.
And that's most of the "marketing" that's needed for a free, open-source tool. When that's lacking, I have to wonder to what extent the tool was actually made to solve somebody's problems. As opposed to being created because the developer was excited to build a thing as a technical exercise. Either path is fine, of course, but it's a mistake to confuse the two.
To me, writing code is very much the same way - it is a human endeavor. But, over the years, I have learned that just not all people are the same way, and that's okay, too.
Growing up, one of the jobs I took was as a system's administrator at the same company my father worked at. It was a small company, maybe six people or so, doing contract work for aerospace. One of the older men who worked there held his Ph. D. in aerospace engineering. He was kind, warm and brilliant... but he struggled with things like sending coherent emails to clients. But that was okay - other people were able to take that on.
That's totally fair. But...going on a hunch, such a person would also make a crude 90s-style website.
Whoever made this clearly knows about slick presentation --- they've got all those colors and shapes pizzas --- so they either capable with slick communications, or work with someone who is. My patience for lack of explanation is therefore a lot thinner.
I'm talking about "marketting" to other software developers, not to non-software developers. Communication with people like oneself is a core skill, not a specialized trade.
This isn't a paid product, after all.
(I'm also a traditionalist that thinks writing good prose and writing good programs are related skills.)
Do you realize the “sell something to people” industry has been at least as big as the tech industry for many decades and is the one growing faster and faster?
Also marketing has historically been a problem for people who make stuff.
Also, better have the Balkans of software than the USSR of mega corps.
Thanks for all the hard work! I'm very excited to see where this goes.
Have you considered sponsoring, or accepting donations, to work on IDE integration? That's pretty much the only reason I migrated my current employers codebase over to Bazel instead of Please.
Hey! Glad you liked it :D Please is owned by Thought Machine. They’ve recently (8 months) brought me on the project full time. We’re planning on putting together a dedicated IDE team together but no promises.
Bazel has a lot of things "missing" that had to be cut out from the OSS release. Things like grpc rule sets are extremely fragmented right now. It's a bit of A saying "the B team should maintain the rules" and B saying "the A team should maintain the rules". As such almost every single language has inconsistent support for everything: code coverage, protobuf, grpc, external dependency management, IDE integration. Also because there's no stubby, sponge, or other cool internal tools a lot of the benefits from blaze as a system are not externalized.
Also, the docker support in Bazel is pretty "different". It's not bad, but it's not immediately obvious to newcomers how this is meant to work.
A few sample build configs of varying complexity would be nice to see at a glance to understand what you are getting into without digging through the weeds.
With that being said I have put a good amount of work into the QuickStart.
The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’d love to hear it.