7 ms·

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 rec

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.

gravypod 6y ago
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.
- tatskaari 6y ago
  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.
- sdenton4 6y ago
  As a big fan of Bazel (ok, Blaze), I'm curious what's different than what Blaze offers
  - gravypod 6y ago
    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. It's getting better every day though.
RangerScience 6y ago
Thank you for making this! 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.
- ironmagma 6y ago
  Are you referring to this [1]? I had to click Documentation to get here and still didn’t see any code... [1] http://sinatrarb.com/documentation.html http://sinatrarb.com/documentation.html
  - BerkhanBerkdemi 6y ago
    I think he was referring to the Intro page [1][2]. [1] http://sinatrarb.com/intro.html http://sinatrarb.com/intro.html [2] https://github.com/sinatra/sinatra#readme https://github.com/sinatra/sinatra#readme
    - RangerScience 6y ago
      I was referring to the landing page: http://sinatrarb.com/ http://sinatrarb.com/
      - ironmagma 6y ago
        Oh, sorry, that didn't show up on mobile. I understand now, thanks.
catlifeonmars 6y ago
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?
- archangel_one 6y ago
  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)
karmakaze 6y ago
What was/is the motivation for this build system that an existing one doesn't satisfy?
- archangel_one 6y ago
  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...
  - bertr4nd 6y ago
    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. )
  - laurentlb 6y ago
    fyi, Starlark dropped compatibility with Python 2 two years ago (https://github.com/bazelbuild/starlark/issues/27 https://github.com/bazelbuild/starlark/issues/27) People interested in type annotations can check this discussion: https://github.com/bazelbuild/starlark/issues/106 https://github.com/bazelbuild/starlark/issues/106 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)
  - karmakaze 6y ago
    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.
rhencke 6y ago
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. Edit: zig is a beautiful exception (https://ziglang.org/download/0.3.0/release-notes.html#caching https://ziglang.org/download/0.3.0/release-notes.html#cachin...)
- liuliu 6y ago
  Incremental builds with the said tools (Please, Bazel) should be a non-issue due to emphasis on hermetic build from these tools.
  - rhencke 6y ago
    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.
    - lattay 6y ago
      For such a system it is only reasonable to have such an escape hatch but maybe a global config forbiding its use would solve your problem ?
    - tomlu 6y ago
      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.
weaksauce 6y ago
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.
Ericson2314 6y ago
This makes me sad. 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. NIH in FOSS is not free.
- rhencke 6y ago
  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.
  - Ericson2314 6y ago
    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.)
  - wpietri 6y ago
    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.
    - rhencke 6y ago
      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.
oblio 6y ago
You should also say upfront that it doesn't support Windows.

gravypod 6y ago

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.

tatskaari 6y ago
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.
sdenton4 6y ago
As a big fan of Bazel (ok, Blaze), I'm curious what's different than what Blaze offers
- gravypod 6y ago
  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. It's getting better every day though.

RangerScience 6y ago

Thank you for making this! 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.

ironmagma 6y ago
Are you referring to this [1]? I had to click Documentation to get here and still didn’t see any code... [1] http://sinatrarb.com/documentation.html http://sinatrarb.com/documentation.html
- BerkhanBerkdemi 6y ago
  I think he was referring to the Intro page [1][2]. [1] http://sinatrarb.com/intro.html http://sinatrarb.com/intro.html [2] https://github.com/sinatra/sinatra#readme https://github.com/sinatra/sinatra#readme
  - RangerScience 6y ago
    I was referring to the landing page: http://sinatrarb.com/ http://sinatrarb.com/
    - ironmagma 6y ago
      Oh, sorry, that didn't show up on mobile. I understand now, thanks.

catlifeonmars 6y ago

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?

archangel_one 6y ago
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)

karmakaze 6y ago

What was/is the motivation for this build system that an existing one doesn't satisfy?

archangel_one 6y ago
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...
- bertr4nd 6y ago
  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. )
- laurentlb 6y ago
  fyi, Starlark dropped compatibility with Python 2 two years ago (https://github.com/bazelbuild/starlark/issues/27 https://github.com/bazelbuild/starlark/issues/27) People interested in type annotations can check this discussion: https://github.com/bazelbuild/starlark/issues/106 https://github.com/bazelbuild/starlark/issues/106 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)
- karmakaze 6y ago
  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.

rhencke 6y ago

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. Edit: zig is a beautiful exception (https://ziglang.org/download/0.3.0/release-notes.html#caching https://ziglang.org/download/0.3.0/release-notes.html#cachin...)

liuliu 6y ago
Incremental builds with the said tools (Please, Bazel) should be a non-issue due to emphasis on hermetic build from these tools.
- rhencke 6y ago
  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.
  - lattay 6y ago
    For such a system it is only reasonable to have such an escape hatch but maybe a global config forbiding its use would solve your problem ?
  - tomlu 6y ago
    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.

weaksauce 6y ago

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.

Ericson2314 6y ago

This makes me sad. 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. NIH in FOSS is not free.

rhencke 6y ago
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.
- Ericson2314 6y ago
  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.)
- wpietri 6y ago
  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.
  - rhencke 6y ago
    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.

oblio 6y ago

You should also say upfront that it doesn't support Windows.