17 ms·

Please – A cross-language build system

318 points by siliconmountain 6y ago

nindalf 6y ago
Title can possibly be modified to mention that this is a tool to build code.
- Yajirobe 6y ago
  > Please (please.build) 'build' kind of indicates that
  - samspenc 6y ago
    Unfortunately for those of us following HN through RSS readers (like Feedly) the URL doesn't show until you mouse over the link ... but even then, I agree adding that additional piece of information such as "build software" would be useful.
    - kanjus 6y ago
      Feedly has an API, I started writing a script a while ago to improve some RSS feeds, including HN (by making the number of comments and the URL appear in the body), but never finished it. If someone had the same idea, please don’t hesitate sharing.
    - gumby 6y ago
      Most RSS clients don’t have that bug.
  - anoncake 6y ago
    Since far from all TLDs have reliable semantics and it's impossible to know all of them, it doesn't. And compiling a project from source code is not the only meaning of "build", not even in tech.
  - sundarurfriend 6y ago
    From the URL, I thought it was going to be a joke page about developers praying "come on, please build!" at complex build systems.
  - webmaven 6y ago
    > > Please (please.build) > 'build' kind of indicates that Not the GP, but as a developer reasonably conversant with build systems and their pain points, I still assumed this was going to be some form of lazyweb[0] related blog post or portal rather than a build system named 'Please'. [0] https://ftrain.com/dear-lazyweb https://ftrain.com/dear-lazyweb
  - nemetroid 6y ago
    With the URL, I was expecting an opinion piece along the lines of https://a16z.com/2020/04/18/its-time-to-build/ https://a16z.com/2020/04/18/its-time-to-build/.
- hyperrail 6y ago
  For what it's worth, I think the too-short title is pretty normal for HN. I'd blame its less than optimum informativeness on HN's cultural norm of short link titles, as reinforced by the administrators' moderation.
scarmig 6y ago
Style issue: the left nav text often overflows into the content area on mobile, making it painful to read.
tsukikage 6y ago
"Installing: curl https://get.please.build https://get.please.build | bash" ...one can stop reading there: this product is not aimed at this community.
- aratno 6y ago
  I don’t think this is a fair reason to write the tool off. They support Homebrew, and I’m sure will add other install methods in the future. Piping to bash is no worse than clicking “yes” on every step of an install wizard.
  - nerdponx 6y ago
    Often these "pipe to Sh scripts" support --help and a variety of configuration options anyway. The benefit of a script over a binary installer at least is that you can inspect the script before running it!
    - geofft 6y ago
      Have you inspected one of these scripts? What have you found? (I've tried it a few times and haven't felt like I learned anything meaningful from doing so.)
      - nerdponx 6y ago
        Yes, plenty of times. Usually I find that they do what you would expect them to do: set up a bunch of parameters like an installation prefix, and then copy files around. They also handle user input options and maybe prompt for some stuff.
      - theamk 6y ago
        I did! The usual annoying thing is the automated package install. I have not looked at this particular package, but in the past, I have seen: - installing specific gcc version and making it system-default. - installing “virtualbox” packages - this was the worst, as the machine had a few KVM VMs running at the same time, and KVM and VirtualBox cannot run at the same time. In general, I now stay away from every install script, and if I cannot, then I run it in docker container. Life is short, I do not want to spend it fixing my primary workstation. (And I examine postinst scripts in deb files too, but those are usually much more boring)
offbyone 6y ago
I love build tools, and work with them professionally, and this tool seems to be getting one thing quite right: it is not injecting itself into the dependency resolution process. Where I see build tooling fall down is where they try to replace the idiomatic dependency modeling tools that exist in each language. The build logic and CLI experience looks to be well thought out. I really like the native sandboxing support and the intentional exclusion of the calling environment. There's a lot of polish here.
- iab 6y ago
  Agreed - pretty seamless chain from build to execution
- s_gourichon 6y ago
  I read Please website (main page, "Getting Started" and FAQ), and still ain't sure about the benefits. To the maintainers of Please: please make cases and user stories, also comparisons with other build tools. Many visitors will jump on each "comparison with tool X" where X=each of the current tools I'm familiar with. Only "Bazel, Buck or Pants" are mentioned. Okay no JVM, looks like Please is a better thought out Blaze/Buck. Please mention CMake and others, like the C/C++-oriented http://floooh.github.io/fips/ http://floooh.github.io/fips/ (a high-level build system "similar to Rust’s Cargo or Javascript’s NPM, but for C/C++ projects.").
mdoms 6y ago
It's hard to tell what the value proposition is here, apart from vague hand-waving about parallelization. The quick start is not enough to get started actually building something. Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.
- Asmodean 6y ago
  For me it has the feeling of something I would play around with in my free time. But as a drop in replacement I agree, it's a bit of a hard sell for me.
  - iab 6y ago
    If you have used (e.g) bazel before, I strongly encourage you to give it a bash, very easy to pickup and “feels good” to use
  - tatskaari 6y ago
    Yup fair enough. Migrating build systems is hard. I've put some work into making migrating from a `go build` project to Please a bit easier. Banzai cloud recently migrated their [Pipeline](https://github.com/banzaicloud/pipeline https://github.com/banzaicloud/pipeline) project over to use Please but admittedly it was quite a lot of work for them.
- throwaway894345 6y ago
  Typically (general purpose) build systems make you choose between reproducibility and performance. Please and other related tools aim to change that (however, in my experience they all fail for one reason or another—not because the problem is inherently intractable but rather because these tools are underinvested-in such that they’re infeasible for smaller organizations to operate and larger organizations can afford to roll their own in-house and get the benefits of a tool suited to their specific needs).
  - pbronez 6y ago
    I think this “missing middle” is a common pattern in expert tools. The economics are challenging because people quickly move through the skill level where the tools are most useful.
gravypod 6y ago
Please build is really fantastic and I loved using it. If it had better ide integrations I'd recommend it over bazel for oss work. It's extremely fast and we'll documented and the community seems very welcoming. Glad it's getting some discussion on HN. Can't wait to hear other's experiences.
- bartvk 6y ago
  So what language do you build with it? And why was it better than the traditional build system of that language?
  - iab 6y ago
    Plz is great for c++, and has a better workflow (IMO) vs (e.g) Cmake. The skylark-like syntax is easier to reason through than cmake generative expressions. Also the use of “plz run” vs “cmake -g; make; run”
    - scaladev 6y ago
      cmake generator only needs to be run once per project. After that you use make or ninja directly, and it regenerates the build files if necessary. I can't say it's a strong argument against cmake.
      - zulu-inuoe 6y ago
        This added user complexity is exactly the argument for plz, though. One of the ideas touted is (to my mind) tight integration, in that plz knows how to handle everything. Whereas cmake just makes project files and leaves it at that.
        nickelpro 6y ago
        Are build tools targeted at end-users? Cmake is better for me, the developer, the person who has to build the software
      - 6y ago
XCSme 6y ago
The landing page on desktop is impossible to read, random text spread all over the screen, no idea what's the intended text flow.
siliconc0w 6y ago
I can imagine a project that successfully replicates the entire google developer environment (distributed build system w/ caching, monorepo with presubmit checks, code review, testing, etc) would be successful since ex-googlers would be likely to advocate for it inside their own organizations and most orgs don't have the engineering time to build all this themselves. Without this tooling large organizations tend to silo which creates high engineering costs (every project starts from scratch, no shared frameworks/libraries, no standardizing around best practices, etc).
- gabereiser 6y ago
  Silo’d development isn’t a matter of tooling, it’s a matter of communication.
  - BobbyJo 6y ago
    And tooling. If tooling is consistent engineers feel much more confident crossing borders. No one speaks up or contributes without confidence.
  - geofft 6y ago
    There's an interplay between them. Communication always has a cost; there are certainly things you can do to the constant factors, but in a 100-person engineering organization with 20 teams, it's fundamentally going to be much easier for an engineer on one team to write a build system (or pre-merge CI flow, or whatever) that meets the needs of their four teammates working on the same code than one that meets the needs of all 20 teams. The advantage of a running, pre-existing system (and the theoretical advantage of an off-the-shelf system like this that you can supposedly turn into a running system) is that it's been built to satisfy most of the needs of a wide variety of developers working on all sorts of things, and so each engineer on each of those teams that says "All right, I'll spend some time thinking about how we build and release code" is incentivized to start from the common starting point, even if they have to customize it. That means that if two or three teams end up working on similar-enough projects down the line, the shared tooling can actually support communication between the teams. Without the shared tooling, they can communicate all they want, but it won't be rational for any team to abandon its existing tooling. (And of course you need the communication too - both are required.)
geofft 6y ago
How easy is it to "port" BUILD files between the various open implementations (Bazel, Buck, Pants, Please)? If you have a project someone else wrote with the intention of using it in e.g. Bazel, can you integrate it into your Please build system, or would you need to treat it as an opaque build process (same as if you were shelling out to ./configure && make)? As a concrete example, one frustration at $DAYJOB is that building certain Google-released OSS is hard to integrate with our existing build system because Bazel is pretty opinionated about compiler-provided headers, output paths, etc. We're calling Bazel as a subprocess during our build and making various files available to it to make our compiler build visible to it, and then we pack up the results. I'm pretty sure if we somehow adopted Bazel for our entire build this would be much better - would it also be better if we adopted one of those other systems? (Maybe one way of asking this is, are any of the corporate sponsors of Buck, Pants, or Please building third-party Bazel code from source? Or vice versa?) A broader question: would it be worth defining a compatible subset of BUILD file syntax and library calls (i.e., not just Starlark but also the rules themselves for common things like building C libraries or JARs)? Are we in the build-system equivalent of the vendor-specific C / C++ / UNIX implementations, and will a cross-vendor standardization effort emerge one day?
- iab 6y ago
  For the first part of your question - it is not 1:1. There is some limited capacity for bazel integration, but massaging is needed (IME) for protos, nvcc rules & so on
- emidln 6y ago
  I've only seriously worked with bazel, but it seems pants and bazel have at least enough compatibility for twitter to migrate to bazel. They gave a talk[0] at bazelcon this year about the effort. [0] https://opensourcelive.withgoogle.com/events/bazelcon2020/watch?talk=day1-talk2 https://opensourcelive.withgoogle.com/events/bazelcon2020/wa...
- laurentlb 6y ago
  I used to work on Bazel and Starlark. In the past, I talked with engineers working on other build systems to aim for some compatibility. The was some interest (even Microsoft people were interested to support Starlark rules in their tool), but it didn't work. On the BUILD file level, Buck is using the Starlark. Pants and Please are close enough that some tooling (e.g. buildifier) can be shared. But that's about it.
arcticfox 6y ago
Admitting ignorance here, I have never intentionally used a build system like this. My normal process for e.g. Python deployment is to write a Dockerfile that installs the dependencies, installs packages, and then copies my user code in. Then I use Pulumi to upload that image to a Docker repository & deploy it to a k8s instance. What am I missing by doing that? This looks really slick, but I'm not sure how, why, or where to use it.
- iab 6y ago
  Speaking from my own limited experience, plz works really well for compiled languages, and total-build approaches (everything from source). I am not sure how much of a multiplier it is for python, apart from finer-grained dependency control and good sandboxing
- theamk 6y ago
  Those kinds of systems are for building stuff, they assume and have multiple build steps with complex dependency relations (like autogen header -> Compile -> link -> test), and that each step takes dozens of seconds and maybe even minutes. In your case, it seems you only have one non-trivial step: python dep install. So this system will be quite overkill for you.
- tatskaari 6y ago
  Please excels in a mono-repo situation. We built Please because we struggled to get Buck to handle Python, Javasript, and Java while having protobuf code generation for all these languages. Fast forward 5 years, now we're using Please to build all our code, generate hashes for docker images, template those hashes into our k8s .yamls, generate the documentation website from the docstrings in the proto files etc. etc. With a language specific build system, you would have a lot of trouble handling things like this.
oblio 6y ago
They make some lofty claims about Python packaging, has anyone used this tool in a reasonably high stakes environment for Python? How was the experience?
TheRealPomax 6y ago
"Please supports Linux, macOS and FreeBSD at the moment" Let me know when I can actually use this on any machine I have to work on, instead of going "fuck you, Windows users". Writing cross-platform build tooling isn't rocket science, it's a choice. And the choice made here is stupidly disappointing in near as makes no difference 2021.
- joncfoo 6y ago
  Is this type of response called for? Please be a good netizen. If you’re interested in the project and are a Windows user, contribute to the project.
- iab 6y ago
  I can see your point, pretty aggravating. Is WSL an option?
  - archangel_one 6y ago
    Hi, one of the implementors here... Yes, WSL is an option, and I believe Please works just fine in it. Right now we don't have any CI etc set up so we can't stand behind it and say "this works", but it works in WSL as most Linux things do.
    - iab 6y ago
      Great stuff, thanks for this great addition to the build ecosystem
- vips7L 6y ago
  Devs on Unix are by the far the worst when it comes to writing cross platform code. This is written in go! How isn't it cross platform?!
  - numbsafari 6y ago
    Maybe if windows were free to use, folks who are volunteering their time and energy would be more prone to support it. Alas...
bitdivision 6y ago
I came across the Pants build system [1] the other day, which looks like it shares some similarities. Though currently very specific to Python. The value proposition is also a bit more clearly defined there [2] [1]: https://www.pantsbuild.org/docs/welcome-to-pants https://www.pantsbuild.org/docs/welcome-to-pants [2]: https://www.pantsbuild.org/docs/how-does-pants-work https://www.pantsbuild.org/docs/how-does-pants-work
- tatskaari 6y ago
  Hey, Please maintainer here! One of the big differences to the other Blaze like build systems is Please actually doesn't treat any of the built in languages any differently to other languages. They are implemented entirely in the build language which is totally open to you as a consumer of Please. Another big difference is Please is written in Go so there's no dependency on VMs or runtimes.
  - klodolph 6y ago
    Bazel is moving in that direction too—the C/C++ rules are built-in, but they’re slowly being extracted into Starlark.
maxpert 6y ago
Have used it in a go mono-repo. It’s own convention on packages and bad integration with IDE makes it a hard sell for me. I mean I just paid for Goland IDE why would I waste my time integrating with something that might or might not work for others. It’s a very hard sell.
- iab 6y ago
  Would you consider it for other mono-repo language projects?
- klodolph 6y ago
  Go tools in general have poor integration with build systems other than "go build". One trick I find useful is to use Go modules (and therefore goimports, not goreturns) and structure your build so that it looks like a standard Go module build, even though it's really being built by some other system. In other words, it's a mix of making the build system conform to Go norms and making your IDE adapt to the remaining differences.
  - tatskaari 6y ago
    I recently added a config option so plz test will run tests in the package directory rather than the repo root (just like go test). Should make things a little easier.
codeulike 6y ago
The number of times I've said "Please build" to myself, over the decades ...
rthomas6 6y ago
I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?
- throwawaylabor 6y ago
  Make build configurations can be difficult to understand for newcomers in the industry. If the goal is to obscure the code, by all means continue using the older tools. If the goal is continued maintenance, then encouraging new engineers to explore and read the codebase with tools they can comprehend is critical. disclaimer: have not used these particular tools, but the domain is nice and polite
  - junon 6y ago
    I have use all of these tools and your take isn't accurate at all. Make doesn't obfuscate anything more than Plz or CMake or whatever. Here are some real reasons why Make isn't the end-all: - Make doesn't allow platform selection in a nice way. - Make doesn't work on Windows natively (no, NMake doesn't count). - Recursive make doesn't work well at all. - Make doesn't track byproducts or deleted artifacts. - Make doesn't have auto-clean. - Make doesn't facilitate out-of-source builds. - Make itself isn't a scripting language (arguably good/bad). - Make doesn't facilitate compiler selection cross-platform, so things like MSVC are nearly impossible to integrate nicely without the use of the developer tools prompt. - Make can't (elegantly) handle a number of rule cases, such as single-input multiple-output rules (it can, but it's a hack). Not sure why you think Make is unapproachable. That's like saying shell scripting is unapproachable. No developer worth a damn is going to avoid shell scripting, and as long as they understand "this file turns into this file using this command" then Make makes sense. As with all tools, Make and Autotools and CMake and probably Plz will be misused by developers that think they're being clever. In actuality, they make things worse at best and unusable/unmaintainable at worst. As a build systems designer, I've evaluated Plz personally and found it to be neat but not suitable for most of the problems I think build systems should solve.
deleted 6y ago
[deleted]
sgt 6y ago
Would be interested how feasible it would be to replace Jenkins with this?
- archangel_one 6y ago
  Please is a pretty different tool to Jenkins - you could use it within Jenkins, but instead of make / Gradle / go build / cargo / etc. It does have some features to facilitate CI and testing at scale, e.g. `plz query changes` can be used to find a minimal set of tests to run for a PR.
japgolly 6y ago
> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?
- dfgdghdf 6y ago
  Some people really dislike the JVM, and Please is written in Go.
  - ur-whale 6y ago
    Exactly what I was about to say. Bazel is a monstrosity in terms of how much shite it pulls in to get started.
    - klodolph 6y ago
      Is it a monstrosity? You need the JVM but the JVM doesn’t seem like a monster to me.
      - zimbatm 6y ago
        The JRE is 655.8M on my system.
        klodolph 6y ago
        And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing in under 50MB. Some people are under the mistaken impression that you have to install the JVM first and then install Bazel, which is simply not true.
jart 6y ago
First thing every software engineer does after leaving Google is rewrite Blaze. Just like every site reliability engineer rewrites borgmon. What I chose to do myself was make Blaze happen using a Makefile config. There's a blog post somewhere where Google talks about why they switched from GNU Make to Blaze c. 2006. if I remember correctly it basically boiled down to not having strict dependency checking. So I thought, why not simply avoid their published mistakes without changing build systems? I learned everything I could about make, discovered that variables are secretly lambdas, and that enabled me to figure out a way to have a static archive package for each folder, which also avoided the need to write a makefile code generator. Then I wrote a simple C program to check incremental elf symbols so the build graph stays sanely formed. It totally got make working like a dream in a way I simply hadn't seen before. https://github.com/jart/cosmopolitan/blob/master/tool/build/package.c https://github.com/jart/cosmopolitan/blob/master/tool/build/...
- klodolph 6y ago
  Every ex-Google SRE I know is glad they don’t have to deal with Borgmon anymore. I don't think it’s popular these days.
  - jart 6y ago
    All the more reason to invent something that improves upon it, since love it or not, it's a must have tool.
    - klodolph 6y ago
      A Google engineering manager once told me that “back in the day, SREs got promoted for writing monitoring systems, and so we ended up with a bunch of unsupported monitoring systems”
    - joshuamorton 6y ago
      Not really, it's barely used anymore. Monarch has replaced it for most situations.
- 6y ago
tatskaari 6y ago
Hey guys! Thanks for checking Please out! I see a lot of recurring themes in the comments so I thought I would clear some things up. What is Please? Please is a multi-language build system designed for huge mono-repos. It was created by a couple frustrated ex-googlers who were familiar with Blaze (which was later open sourced as Bazel). We found the "real world" alternatives to be somewhat lacking and so Please was born! Please draws inspiration on the Blaze paradigm. If you're familiar with Bazel, the biggest difference is Please aims to be simpler and have far less magic in the binary. We push the implementation of the build rules into the build language, dog feeding them to ensure Please is flexible enough for any task. Also Please is written in Go so doesn't require a JVM ;) If you're not familiar with Blaze/Bazel, here's what all the fuss is about: 1) Hermetic builds: builds are run in their own tightly controlled environment. Each step of the build runs in their own temp directory isolating them from other steps and only having access to the files and environment variables they've declared as their inputs. Please also has sandboxing built in taking advantage of the linux kernel to further isolate tests. 2) Scalability through incrementallity: if you've used Make, you're probably familiar with caching problems. Make uses last modified timestamps on files to determine if they need to rebuild each step, which turns out is fallible. Please uses a hash based approach which is far more robust. Most of our developers don't even know how to clean the cache. As a result, we can incrementality build our entire repository locally and on our CI workers no matter how big our repo gets. 3) Flexibility: the build language is a dialect of python. This can be used to write "build definitions" which define a unit of work i.e. compiling a Go package. There's nothing special about the built in definitions; it's totally possible to write your own to automate nearly any part of your development process. You could generate code, template kubernetes .yamls and beyond! 4) Unified developer experience: The please command line provides a unified experience across your codebase. Want to test all the tests under a branch of your repo? `plz test //some/part/of/the/repo/...`. It doesn't matter what language you're using, what those tests depend on etc. etc. Please can always run them for you. PS: Apologies for the website. We're a small team of build system engineers, not front end types. If you want to offer your skills, I'd be happy to point you in the right direction: https://github.com/thought-machine/please https://github.com/thought-machine/please.
- deleted 6y ago
  [deleted]
zellyn 6y ago
I like the idea of please.build. But I'd like it more if it used Starlark :-( https://github.com/thought-machine/please/issues?q=is%3Aissue+skylark https://github.com/thought-machine/please/issues?q=is%3Aissu... https://github.com/thought-machine/please/issues?q=is%3Aissue+starlark https://github.com/thought-machine/please/issues?q=is%3Aissu...
pdimitar 6y ago
Can somebody sell me this tool while comparing it to `make`, or Elixir's `mix`, or Rust's `cargo`?
- s_gourichon 6y ago
  Or CMake or the C/C++-oriented http://floooh.github.io/fips/ http://floooh.github.io/fips/ (a high-level build system "similar to Rust’s Cargo or Javascript’s NPM, but for C/C++ projects.").
- numbsafari 6y ago
  If you are working in an environment that needs to mix between different languages, and a monorepo makes sense for you, then a tool like please let’s you stitch those things together and handles dependencies between those things. So if you have a service defined in an IDL like gRPC or OpenAPI, with a backend in python and a web front-end in JS, and API docs, etc, a tool like this can stitch together changes really efficiently. Please is a lot more lightweight than Bazel, so it’s easier to get deployed and work with different projects. The new maintainer has been shaving off a lot of warts lately and it’s getting a lot better. If the above doesn’t describe your situation, then a tool like please, pants, buck, or bazel is probably not for you. And that’s ok too.
lxe 6y ago
Wish there was a new generation high level build system like this or Bazel or something but with decent JavaScript/node_modules support.
- thundergolfer 6y ago
  The Bazel and JS story is in its infancy. Things will get better once certain big companies have time to adopt and mature into it.
underdeserver 6y ago
This looks great. A minimalist no-BS version of Blaze that supports everything I would need is something I'd be happy to use.
dblotsky 6y ago
How big does the project have to be in order for this system to have benefits over Make?
- jrockway 6y ago
  The problem with Make is that it doesn't know what it's building, so it can't do anything smart. For incremental builds to work at all, you have to supply the smarts. Having worked on a number of make-based projects (I am most scarred by buildroot), I can tell you that people make mistakes with build rules. The project then devolves to doing a clean build for every change, turning what could be a few milliseconds of CPU time into a 30 minute rebuild. The idea of these build systems like Bazel is that the rules are correct so that you don't have to worry about writing correct rules, and you have a high probability of an incremental build producing a binary that's bit-for-bit identical to one from a full build. The result is that you don't do full builds anymore, and save the latency of waiting for things to build. (That latency shows up in the edit-build-test cycle, how long it takes to deploy software to production to fix an emergency bug, etc. So it's important!)
  - dblotsky 6y ago
    I am personally not convinced that any build system can be correct and general, but perhaps that’s my lack of experience speaking. On that 30 minute note though: so, how big does the project need to be in order for Make not to be enough? And at that size, why wouldn’t the project invest the extra week it takes to get the Makefile correct?
    - laurentlb 6y ago
      It's easier to adopt a correct build system when your codebase is still simple. It can save you time, because it can prevent lots of unintentional errors over time (e.g. you might not notice when you get an incorrect result after an incremental build). In my opinion, this is a bit similar to languages with static vs dynamic typing. If your current setup works well for you, it makes sense to keep it, though.
    - 6y ago
Areading314 6y ago
At some point it becomes actively harmful to build and publicize tools that further the fragmentation of an ecosystem. We need a unified build system, not yet another build system. To get there we have to contribute to existing tools to keep making them better.
CharlesMerriam2 6y ago
Why are landing pages so incredibly uninformative? In practice, I spend under two minutes to click around and see if can 'get' it. What does it do especially well? What's the syntax look like? If you are brave, what doesn't work well? No idea why this exists or why I would use it. Bad website. No cookie.
high_priest 6y ago
I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast written codebase and disregard for proper, complete documentation. "Because you can just read and understand the code", yeah I can do the same in well maintained code of a faster language.
- skulk 6y ago
  Are build systems typically CPU bound, even during heavy operations such as calculating dependency closure (or other things I'm unaware of)? If not, the I don't see a need to use a language that doesn't provide high level, somewhat costly, but easy to use and understand abstractions. And if it's faster than its competitors and it weighs less, then there's also nothing wrong with calling it "fast" and "lightweight" (though I have no idea whether please fulfills this)
  - damnyou 6y ago
    Build system performance tends to be IO-bound, but responsiveness for things like no-op builds tends to be CPU-bound -- and the JVM in particular really suffers. Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use. Arguably, making tools feel better to use is more important than raw performance. When you're doing a no-op build, the difference between 100 milliseconds and 500 is large, and the difference between 10ms and 100 is enormous.
    - matheusmoreira 6y ago
      > Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use. Optimizing I/O performance certainly makes building software feel better though. Running make on a tmpfs directory feels absolutely amazing. It feels even better on subsequent runs since Linux uses free memory to cache files.
jto1218 6y ago
> Indentation is normally four spaces. Tabs will be rejected by the parser. You love to see it.
dsagal 6y ago
Is there any help from Please on building TypeScript projects faster?
- tatskaari 6y ago
  It's pretty easy to wrap the typescript compiler however I've not seem many people use pure TS like that. Mostly people want to use webpack and TS together. Unfortunately webpack doesn't expose anything that would allow us to incrementally build a webpack bundle.
mleonhard 6y ago
Does Please allow one to easily specify a specific JDK version to use to build and run tests? I wasted a lot of time getting Bazel to use a modern JDK.
waruqi 6y ago
I prefer xmake https://github.com/xmake-io/xmake https://github.com/xmake-io/xmake
JensRantil 6y ago
If I was building a company today I would use Earthly instead of Buck, Bazel or Please. I think Earthly gets out of the way of actually low-level builds and instead focusing on high-level, Dockerised targets. The benefits range from allowing proper IDE support, to very easy system/integration tests, while still reaping the benefit of remote execution and aggressive caching.

nindalf 6y ago

Title can possibly be modified to mention that this is a tool to build code.

Yajirobe 6y ago
> Please (please.build) 'build' kind of indicates that
- samspenc 6y ago
  Unfortunately for those of us following HN through RSS readers (like Feedly) the URL doesn't show until you mouse over the link ... but even then, I agree adding that additional piece of information such as "build software" would be useful.
  - kanjus 6y ago
    Feedly has an API, I started writing a script a while ago to improve some RSS feeds, including HN (by making the number of comments and the URL appear in the body), but never finished it. If someone had the same idea, please don’t hesitate sharing.
  - gumby 6y ago
    Most RSS clients don’t have that bug.
- anoncake 6y ago
  Since far from all TLDs have reliable semantics and it's impossible to know all of them, it doesn't. And compiling a project from source code is not the only meaning of "build", not even in tech.
- sundarurfriend 6y ago
  From the URL, I thought it was going to be a joke page about developers praying "come on, please build!" at complex build systems.
- webmaven 6y ago
  > > Please (please.build) > 'build' kind of indicates that Not the GP, but as a developer reasonably conversant with build systems and their pain points, I still assumed this was going to be some form of lazyweb[0] related blog post or portal rather than a build system named 'Please'. [0] https://ftrain.com/dear-lazyweb https://ftrain.com/dear-lazyweb
- nemetroid 6y ago
  With the URL, I was expecting an opinion piece along the lines of https://a16z.com/2020/04/18/its-time-to-build/ https://a16z.com/2020/04/18/its-time-to-build/.
hyperrail 6y ago
For what it's worth, I think the too-short title is pretty normal for HN. I'd blame its less than optimum informativeness on HN's cultural norm of short link titles, as reinforced by the administrators' moderation.

scarmig 6y ago

Style issue: the left nav text often overflows into the content area on mobile, making it painful to read.

tsukikage 6y ago

"Installing: curl https://get.please.build https://get.please.build | bash" ...one can stop reading there: this product is not aimed at this community.

aratno 6y ago
I don’t think this is a fair reason to write the tool off. They support Homebrew, and I’m sure will add other install methods in the future. Piping to bash is no worse than clicking “yes” on every step of an install wizard.
- nerdponx 6y ago
  Often these "pipe to Sh scripts" support --help and a variety of configuration options anyway. The benefit of a script over a binary installer at least is that you can inspect the script before running it!
  - geofft 6y ago
    Have you inspected one of these scripts? What have you found? (I've tried it a few times and haven't felt like I learned anything meaningful from doing so.)
    - nerdponx 6y ago
      Yes, plenty of times. Usually I find that they do what you would expect them to do: set up a bunch of parameters like an installation prefix, and then copy files around. They also handle user input options and maybe prompt for some stuff.
    - theamk 6y ago
      I did! The usual annoying thing is the automated package install. I have not looked at this particular package, but in the past, I have seen: - installing specific gcc version and making it system-default. - installing “virtualbox” packages - this was the worst, as the machine had a few KVM VMs running at the same time, and KVM and VirtualBox cannot run at the same time. In general, I now stay away from every install script, and if I cannot, then I run it in docker container. Life is short, I do not want to spend it fixing my primary workstation. (And I examine postinst scripts in deb files too, but those are usually much more boring)

offbyone 6y ago

I love build tools, and work with them professionally, and this tool seems to be getting one thing quite right: it is not injecting itself into the dependency resolution process. Where I see build tooling fall down is where they try to replace the idiomatic dependency modeling tools that exist in each language. The build logic and CLI experience looks to be well thought out. I really like the native sandboxing support and the intentional exclusion of the calling environment. There's a lot of polish here.

iab 6y ago
Agreed - pretty seamless chain from build to execution
s_gourichon 6y ago
I read Please website (main page, "Getting Started" and FAQ), and still ain't sure about the benefits. To the maintainers of Please: please make cases and user stories, also comparisons with other build tools. Many visitors will jump on each "comparison with tool X" where X=each of the current tools I'm familiar with. Only "Bazel, Buck or Pants" are mentioned. Okay no JVM, looks like Please is a better thought out Blaze/Buck. Please mention CMake and others, like the C/C++-oriented http://floooh.github.io/fips/ http://floooh.github.io/fips/ (a high-level build system "similar to Rust’s Cargo or Javascript’s NPM, but for C/C++ projects.").

mdoms 6y ago

It's hard to tell what the value proposition is here, apart from vague hand-waving about parallelization. The quick start is not enough to get started actually building something. Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.

Asmodean 6y ago
For me it has the feeling of something I would play around with in my free time. But as a drop in replacement I agree, it's a bit of a hard sell for me.
- iab 6y ago
  If you have used (e.g) bazel before, I strongly encourage you to give it a bash, very easy to pickup and “feels good” to use
- tatskaari 6y ago
  Yup fair enough. Migrating build systems is hard. I've put some work into making migrating from a `go build` project to Please a bit easier. Banzai cloud recently migrated their [Pipeline](https://github.com/banzaicloud/pipeline https://github.com/banzaicloud/pipeline) project over to use Please but admittedly it was quite a lot of work for them.
throwaway894345 6y ago
Typically (general purpose) build systems make you choose between reproducibility and performance. Please and other related tools aim to change that (however, in my experience they all fail for one reason or another—not because the problem is inherently intractable but rather because these tools are underinvested-in such that they’re infeasible for smaller organizations to operate and larger organizations can afford to roll their own in-house and get the benefits of a tool suited to their specific needs).
- pbronez 6y ago
  I think this “missing middle” is a common pattern in expert tools. The economics are challenging because people quickly move through the skill level where the tools are most useful.

gravypod 6y ago

Please build is really fantastic and I loved using it. If it had better ide integrations I'd recommend it over bazel for oss work. It's extremely fast and we'll documented and the community seems very welcoming. Glad it's getting some discussion on HN. Can't wait to hear other's experiences.

bartvk 6y ago
So what language do you build with it? And why was it better than the traditional build system of that language?
- iab 6y ago
  Plz is great for c++, and has a better workflow (IMO) vs (e.g) Cmake. The skylark-like syntax is easier to reason through than cmake generative expressions. Also the use of “plz run” vs “cmake -g; make; run”
  - scaladev 6y ago
    cmake generator only needs to be run once per project. After that you use make or ninja directly, and it regenerates the build files if necessary. I can't say it's a strong argument against cmake.
    - zulu-inuoe 6y ago
      This added user complexity is exactly the argument for plz, though. One of the ideas touted is (to my mind) tight integration, in that plz knows how to handle everything. Whereas cmake just makes project files and leaves it at that.
      - nickelpro 6y ago
        Are build tools targeted at end-users? Cmake is better for me, the developer, the person who has to build the software
    - 6y ago

XCSme 6y ago

The landing page on desktop is impossible to read, random text spread all over the screen, no idea what's the intended text flow.

siliconc0w 6y ago

I can imagine a project that successfully replicates the entire google developer environment (distributed build system w/ caching, monorepo with presubmit checks, code review, testing, etc) would be successful since ex-googlers would be likely to advocate for it inside their own organizations and most orgs don't have the engineering time to build all this themselves. Without this tooling large organizations tend to silo which creates high engineering costs (every project starts from scratch, no shared frameworks/libraries, no standardizing around best practices, etc).

gabereiser 6y ago
Silo’d development isn’t a matter of tooling, it’s a matter of communication.
- BobbyJo 6y ago
  And tooling. If tooling is consistent engineers feel much more confident crossing borders. No one speaks up or contributes without confidence.
- geofft 6y ago
  There's an interplay between them. Communication always has a cost; there are certainly things you can do to the constant factors, but in a 100-person engineering organization with 20 teams, it's fundamentally going to be much easier for an engineer on one team to write a build system (or pre-merge CI flow, or whatever) that meets the needs of their four teammates working on the same code than one that meets the needs of all 20 teams. The advantage of a running, pre-existing system (and the theoretical advantage of an off-the-shelf system like this that you can supposedly turn into a running system) is that it's been built to satisfy most of the needs of a wide variety of developers working on all sorts of things, and so each engineer on each of those teams that says "All right, I'll spend some time thinking about how we build and release code" is incentivized to start from the common starting point, even if they have to customize it. That means that if two or three teams end up working on similar-enough projects down the line, the shared tooling can actually support communication between the teams. Without the shared tooling, they can communicate all they want, but it won't be rational for any team to abandon its existing tooling. (And of course you need the communication too - both are required.)

geofft 6y ago

How easy is it to "port" BUILD files between the various open implementations (Bazel, Buck, Pants, Please)? If you have a project someone else wrote with the intention of using it in e.g. Bazel, can you integrate it into your Please build system, or would you need to treat it as an opaque build process (same as if you were shelling out to ./configure && make)? As a concrete example, one frustration at $DAYJOB is that building certain Google-released OSS is hard to integrate with our existing build system because Bazel is pretty opinionated about compiler-provided headers, output paths, etc. We're calling Bazel as a subprocess during our build and making various files available to it to make our compiler build visible to it, and then we pack up the results. I'm pretty sure if we somehow adopted Bazel for our entire build this would be much better - would it also be better if we adopted one of those other systems? (Maybe one way of asking this is, are any of the corporate sponsors of Buck, Pants, or Please building third-party Bazel code from source? Or vice versa?) A broader question: would it be worth defining a compatible subset of BUILD file syntax and library calls (i.e., not just Starlark but also the rules themselves for common things like building C libraries or JARs)? Are we in the build-system equivalent of the vendor-specific C / C++ / UNIX implementations, and will a cross-vendor standardization effort emerge one day?

iab 6y ago
For the first part of your question - it is not 1:1. There is some limited capacity for bazel integration, but massaging is needed (IME) for protos, nvcc rules & so on
emidln 6y ago
I've only seriously worked with bazel, but it seems pants and bazel have at least enough compatibility for twitter to migrate to bazel. They gave a talk[0] at bazelcon this year about the effort. [0] https://opensourcelive.withgoogle.com/events/bazelcon2020/watch?talk=day1-talk2 https://opensourcelive.withgoogle.com/events/bazelcon2020/wa...
laurentlb 6y ago
I used to work on Bazel and Starlark. In the past, I talked with engineers working on other build systems to aim for some compatibility. The was some interest (even Microsoft people were interested to support Starlark rules in their tool), but it didn't work. On the BUILD file level, Buck is using the Starlark. Pants and Please are close enough that some tooling (e.g. buildifier) can be shared. But that's about it.

arcticfox 6y ago

Admitting ignorance here, I have never intentionally used a build system like this. My normal process for e.g. Python deployment is to write a Dockerfile that installs the dependencies, installs packages, and then copies my user code in. Then I use Pulumi to upload that image to a Docker repository & deploy it to a k8s instance. What am I missing by doing that? This looks really slick, but I'm not sure how, why, or where to use it.

iab 6y ago
Speaking from my own limited experience, plz works really well for compiled languages, and total-build approaches (everything from source). I am not sure how much of a multiplier it is for python, apart from finer-grained dependency control and good sandboxing
theamk 6y ago
Those kinds of systems are for building stuff, they assume and have multiple build steps with complex dependency relations (like autogen header -> Compile -> link -> test), and that each step takes dozens of seconds and maybe even minutes. In your case, it seems you only have one non-trivial step: python dep install. So this system will be quite overkill for you.
tatskaari 6y ago
Please excels in a mono-repo situation. We built Please because we struggled to get Buck to handle Python, Javasript, and Java while having protobuf code generation for all these languages. Fast forward 5 years, now we're using Please to build all our code, generate hashes for docker images, template those hashes into our k8s .yamls, generate the documentation website from the docstrings in the proto files etc. etc. With a language specific build system, you would have a lot of trouble handling things like this.

oblio 6y ago

They make some lofty claims about Python packaging, has anyone used this tool in a reasonably high stakes environment for Python? How was the experience?

TheRealPomax 6y ago

"Please supports Linux, macOS and FreeBSD at the moment" Let me know when I can actually use this on any machine I have to work on, instead of going "fuck you, Windows users". Writing cross-platform build tooling isn't rocket science, it's a choice. And the choice made here is stupidly disappointing in near as makes no difference 2021.

joncfoo 6y ago
Is this type of response called for? Please be a good netizen. If you’re interested in the project and are a Windows user, contribute to the project.
iab 6y ago
I can see your point, pretty aggravating. Is WSL an option?
- archangel_one 6y ago
  Hi, one of the implementors here... Yes, WSL is an option, and I believe Please works just fine in it. Right now we don't have any CI etc set up so we can't stand behind it and say "this works", but it works in WSL as most Linux things do.
  - iab 6y ago
    Great stuff, thanks for this great addition to the build ecosystem
vips7L 6y ago
Devs on Unix are by the far the worst when it comes to writing cross platform code. This is written in go! How isn't it cross platform?!
- numbsafari 6y ago
  Maybe if windows were free to use, folks who are volunteering their time and energy would be more prone to support it. Alas...

bitdivision 6y ago

I came across the Pants build system [1] the other day, which looks like it shares some similarities. Though currently very specific to Python. The value proposition is also a bit more clearly defined there [2] [1]: https://www.pantsbuild.org/docs/welcome-to-pants https://www.pantsbuild.org/docs/welcome-to-pants [2]: https://www.pantsbuild.org/docs/how-does-pants-work https://www.pantsbuild.org/docs/how-does-pants-work

tatskaari 6y ago
Hey, Please maintainer here! One of the big differences to the other Blaze like build systems is Please actually doesn't treat any of the built in languages any differently to other languages. They are implemented entirely in the build language which is totally open to you as a consumer of Please. Another big difference is Please is written in Go so there's no dependency on VMs or runtimes.
- klodolph 6y ago
  Bazel is moving in that direction too—the C/C++ rules are built-in, but they’re slowly being extracted into Starlark.

maxpert 6y ago

Have used it in a go mono-repo. It’s own convention on packages and bad integration with IDE makes it a hard sell for me. I mean I just paid for Goland IDE why would I waste my time integrating with something that might or might not work for others. It’s a very hard sell.

iab 6y ago
Would you consider it for other mono-repo language projects?
klodolph 6y ago
Go tools in general have poor integration with build systems other than "go build". One trick I find useful is to use Go modules (and therefore goimports, not goreturns) and structure your build so that it looks like a standard Go module build, even though it's really being built by some other system. In other words, it's a mix of making the build system conform to Go norms and making your IDE adapt to the remaining differences.
- tatskaari 6y ago
  I recently added a config option so plz test will run tests in the package directory rather than the repo root (just like go test). Should make things a little easier.

codeulike 6y ago

The number of times I've said "Please build" to myself, over the decades ...

rthomas6 6y ago

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

throwawaylabor 6y ago
Make build configurations can be difficult to understand for newcomers in the industry. If the goal is to obscure the code, by all means continue using the older tools. If the goal is continued maintenance, then encouraging new engineers to explore and read the codebase with tools they can comprehend is critical. disclaimer: have not used these particular tools, but the domain is nice and polite
- junon 6y ago
  I have use all of these tools and your take isn't accurate at all. Make doesn't obfuscate anything more than Plz or CMake or whatever. Here are some real reasons why Make isn't the end-all: - Make doesn't allow platform selection in a nice way. - Make doesn't work on Windows natively (no, NMake doesn't count). - Recursive make doesn't work well at all. - Make doesn't track byproducts or deleted artifacts. - Make doesn't have auto-clean. - Make doesn't facilitate out-of-source builds. - Make itself isn't a scripting language (arguably good/bad). - Make doesn't facilitate compiler selection cross-platform, so things like MSVC are nearly impossible to integrate nicely without the use of the developer tools prompt. - Make can't (elegantly) handle a number of rule cases, such as single-input multiple-output rules (it can, but it's a hack). Not sure why you think Make is unapproachable. That's like saying shell scripting is unapproachable. No developer worth a damn is going to avoid shell scripting, and as long as they understand "this file turns into this file using this command" then Make makes sense. As with all tools, Make and Autotools and CMake and probably Plz will be misused by developers that think they're being clever. In actuality, they make things worse at best and unusable/unmaintainable at worst. As a build systems designer, I've evaluated Plz personally and found it to be neat but not suitable for most of the problems I think build systems should solve.

deleted 6y ago

[deleted]

sgt 6y ago

Would be interested how feasible it would be to replace Jenkins with this?

archangel_one 6y ago
Please is a pretty different tool to Jenkins - you could use it within Jenkins, but instead of make / Gradle / go build / cargo / etc. It does have some features to facilitate CI and testing at scale, e.g. `plz query changes` can be used to find a minimal set of tests to run for a PR.

japgolly 6y ago

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

dfgdghdf 6y ago
Some people really dislike the JVM, and Please is written in Go.
- ur-whale 6y ago
  Exactly what I was about to say. Bazel is a monstrosity in terms of how much shite it pulls in to get started.
  - klodolph 6y ago
    Is it a monstrosity? You need the JVM but the JVM doesn’t seem like a monster to me.
    - zimbatm 6y ago
      The JRE is 655.8M on my system.
      - klodolph 6y ago
        And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing in under 50MB. Some people are under the mistaken impression that you have to install the JVM first and then install Bazel, which is simply not true.

jart 6y ago

First thing every software engineer does after leaving Google is rewrite Blaze. Just like every site reliability engineer rewrites borgmon. What I chose to do myself was make Blaze happen using a Makefile config. There's a blog post somewhere where Google talks about why they switched from GNU Make to Blaze c. 2006. if I remember correctly it basically boiled down to not having strict dependency checking. So I thought, why not simply avoid their published mistakes without changing build systems? I learned everything I could about make, discovered that variables are secretly lambdas, and that enabled me to figure out a way to have a static archive package for each folder, which also avoided the need to write a makefile code generator. Then I wrote a simple C program to check incremental elf symbols so the build graph stays sanely formed. It totally got make working like a dream in a way I simply hadn't seen before. https://github.com/jart/cosmopolitan/blob/master/tool/build/package.c https://github.com/jart/cosmopolitan/blob/master/tool/build/...

klodolph 6y ago
Every ex-Google SRE I know is glad they don’t have to deal with Borgmon anymore. I don't think it’s popular these days.
- jart 6y ago
  All the more reason to invent something that improves upon it, since love it or not, it's a must have tool.
  - klodolph 6y ago
    A Google engineering manager once told me that “back in the day, SREs got promoted for writing monitoring systems, and so we ended up with a bunch of unsupported monitoring systems”
  - joshuamorton 6y ago
    Not really, it's barely used anymore. Monarch has replaced it for most situations.
6y ago

tatskaari 6y ago

Hey guys! Thanks for checking Please out! I see a lot of recurring themes in the comments so I thought I would clear some things up. What is Please? Please is a multi-language build system designed for huge mono-repos. It was created by a couple frustrated ex-googlers who were familiar with Blaze (which was later open sourced as Bazel). We found the "real world" alternatives to be somewhat lacking and so Please was born! Please draws inspiration on the Blaze paradigm. If you're familiar with Bazel, the biggest difference is Please aims to be simpler and have far less magic in the binary. We push the implementation of the build rules into the build language, dog feeding them to ensure Please is flexible enough for any task. Also Please is written in Go so doesn't require a JVM ;) If you're not familiar with Blaze/Bazel, here's what all the fuss is about: 1) Hermetic builds: builds are run in their own tightly controlled environment. Each step of the build runs in their own temp directory isolating them from other steps and only having access to the files and environment variables they've declared as their inputs. Please also has sandboxing built in taking advantage of the linux kernel to further isolate tests. 2) Scalability through incrementallity: if you've used Make, you're probably familiar with caching problems. Make uses last modified timestamps on files to determine if they need to rebuild each step, which turns out is fallible. Please uses a hash based approach which is far more robust. Most of our developers don't even know how to clean the cache. As a result, we can incrementality build our entire repository locally and on our CI workers no matter how big our repo gets. 3) Flexibility: the build language is a dialect of python. This can be used to write "build definitions" which define a unit of work i.e. compiling a Go package. There's nothing special about the built in definitions; it's totally possible to write your own to automate nearly any part of your development process. You could generate code, template kubernetes .yamls and beyond! 4) Unified developer experience: The please command line provides a unified experience across your codebase. Want to test all the tests under a branch of your repo? `plz test //some/part/of/the/repo/...`. It doesn't matter what language you're using, what those tests depend on etc. etc. Please can always run them for you. PS: Apologies for the website. We're a small team of build system engineers, not front end types. If you want to offer your skills, I'd be happy to point you in the right direction: https://github.com/thought-machine/please https://github.com/thought-machine/please.

deleted 6y ago
[deleted]

zellyn 6y ago

I like the idea of please.build. But I'd like it more if it used Starlark :-( https://github.com/thought-machine/please/issues?q=is%3Aissue+skylark https://github.com/thought-machine/please/issues?q=is%3Aissu... https://github.com/thought-machine/please/issues?q=is%3Aissue+starlark https://github.com/thought-machine/please/issues?q=is%3Aissu...

pdimitar 6y ago

Can somebody sell me this tool while comparing it to `make`, or Elixir's `mix`, or Rust's `cargo`?

s_gourichon 6y ago
Or CMake or the C/C++-oriented http://floooh.github.io/fips/ http://floooh.github.io/fips/ (a high-level build system "similar to Rust’s Cargo or Javascript’s NPM, but for C/C++ projects.").
numbsafari 6y ago
If you are working in an environment that needs to mix between different languages, and a monorepo makes sense for you, then a tool like please let’s you stitch those things together and handles dependencies between those things. So if you have a service defined in an IDL like gRPC or OpenAPI, with a backend in python and a web front-end in JS, and API docs, etc, a tool like this can stitch together changes really efficiently. Please is a lot more lightweight than Bazel, so it’s easier to get deployed and work with different projects. The new maintainer has been shaving off a lot of warts lately and it’s getting a lot better. If the above doesn’t describe your situation, then a tool like please, pants, buck, or bazel is probably not for you. And that’s ok too.

lxe 6y ago

Wish there was a new generation high level build system like this or Bazel or something but with decent JavaScript/node_modules support.

thundergolfer 6y ago
The Bazel and JS story is in its infancy. Things will get better once certain big companies have time to adopt and mature into it.

underdeserver 6y ago

This looks great. A minimalist no-BS version of Blaze that supports everything I would need is something I'd be happy to use.

dblotsky 6y ago

How big does the project have to be in order for this system to have benefits over Make?

jrockway 6y ago
The problem with Make is that it doesn't know what it's building, so it can't do anything smart. For incremental builds to work at all, you have to supply the smarts. Having worked on a number of make-based projects (I am most scarred by buildroot), I can tell you that people make mistakes with build rules. The project then devolves to doing a clean build for every change, turning what could be a few milliseconds of CPU time into a 30 minute rebuild. The idea of these build systems like Bazel is that the rules are correct so that you don't have to worry about writing correct rules, and you have a high probability of an incremental build producing a binary that's bit-for-bit identical to one from a full build. The result is that you don't do full builds anymore, and save the latency of waiting for things to build. (That latency shows up in the edit-build-test cycle, how long it takes to deploy software to production to fix an emergency bug, etc. So it's important!)
- dblotsky 6y ago
  I am personally not convinced that any build system can be correct and general, but perhaps that’s my lack of experience speaking. On that 30 minute note though: so, how big does the project need to be in order for Make not to be enough? And at that size, why wouldn’t the project invest the extra week it takes to get the Makefile correct?
  - laurentlb 6y ago
    It's easier to adopt a correct build system when your codebase is still simple. It can save you time, because it can prevent lots of unintentional errors over time (e.g. you might not notice when you get an incorrect result after an incremental build). In my opinion, this is a bit similar to languages with static vs dynamic typing. If your current setup works well for you, it makes sense to keep it, though.
  - 6y ago

Areading314 6y ago

At some point it becomes actively harmful to build and publicize tools that further the fragmentation of an ecosystem. We need a unified build system, not yet another build system. To get there we have to contribute to existing tools to keep making them better.

CharlesMerriam2 6y ago

Why are landing pages so incredibly uninformative? In practice, I spend under two minutes to click around and see if can 'get' it. What does it do especially well? What's the syntax look like? If you are brave, what doesn't work well? No idea why this exists or why I would use it. Bad website. No cookie.

high_priest 6y ago

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast written codebase and disregard for proper, complete documentation. "Because you can just read and understand the code", yeah I can do the same in well maintained code of a faster language.

skulk 6y ago
Are build systems typically CPU bound, even during heavy operations such as calculating dependency closure (or other things I'm unaware of)? If not, the I don't see a need to use a language that doesn't provide high level, somewhat costly, but easy to use and understand abstractions. And if it's faster than its competitors and it weighs less, then there's also nothing wrong with calling it "fast" and "lightweight" (though I have no idea whether please fulfills this)
- damnyou 6y ago
  Build system performance tends to be IO-bound, but responsiveness for things like no-op builds tends to be CPU-bound -- and the JVM in particular really suffers. Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use. Arguably, making tools feel better to use is more important than raw performance. When you're doing a no-op build, the difference between 100 milliseconds and 500 is large, and the difference between 10ms and 100 is enormous.
  - matheusmoreira 6y ago
    > Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use. Optimizing I/O performance certainly makes building software feel better though. Running make on a tmpfs directory feels absolutely amazing. It feels even better on subsequent runs since Linux uses free memory to cache files.

jto1218 6y ago

> Indentation is normally four spaces. Tabs will be rejected by the parser. You love to see it.

dsagal 6y ago

Is there any help from Please on building TypeScript projects faster?

tatskaari 6y ago
It's pretty easy to wrap the typescript compiler however I've not seem many people use pure TS like that. Mostly people want to use webpack and TS together. Unfortunately webpack doesn't expose anything that would allow us to incrementally build a webpack bundle.

mleonhard 6y ago

Does Please allow one to easily specify a specific JDK version to use to build and run tests? I wasted a lot of time getting Bazel to use a modern JDK.

waruqi 6y ago

I prefer xmake https://github.com/xmake-io/xmake https://github.com/xmake-io/xmake

JensRantil 6y ago

If I was building a company today I would use Earthly instead of Buck, Bazel or Please. I think Earthly gets out of the way of actually low-level builds and instead focusing on high-level, Dockerised targets. The benefits range from allowing proper IDE support, to very easy system/integration tests, while still reaping the benefit of remote execution and aggressive caching.