Earlier quoted context omitted.
Do you think clicking "yes" on an installer is any more secure?
Yes. For starters, it's much harder to suffer disastrous consequences from running truncated command due to terminated network connection when running an installer.
Please – A cross-language build system
41–50 of 257 posts
Re: Please – A cross-language build system
#42It'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.
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.
Re: Please – A cross-language build system
#43Earlier quoted context omitted.
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!
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.)
Re: Please – A cross-language build system
#44Earlier quoted context omitted.
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!
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.)
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)
Re: Please – A cross-language build system
#45"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.
This is written in go! How isn't it cross platform?!
Re: Please – A cross-language build system
#46Re: Please – A cross-language build system
#47Earlier quoted context omitted.
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!
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.)
I've occasionally seen scripts that install some other application where it was not clear that it was a dependency and there was no heads up to the user that this was going to happen: that kind of behavior makes me more distrustful of the author, so there's a useful signal there.
Most scripts like this seem to amount to "configuration defaults + cli completions installation". To that end, I find looking at them useful because it gives me a sense of the expectations of the tooling and hints at where I might find things if I need to go debugging later.
When they are provided by the same entity as the program you wish to run, I don't see how it's significantly more risky to run these scripts than running the application code itself with the active user's permissions. Still, if there was something, by glancing at the script, you have half a chance of seeing it. If there's something there that doesn't make sense, that's both a "proceed with caution" and a learning opportunity.
Re: Please – A cross-language build system
#48It'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.
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’…
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.
Re: Please – A cross-language build system
#49Earlier quoted context omitted.
Yes. For starters, it's much harder to suffer disastrous consequences from running truncated command due to terminated network connection when running an installer.
This is easily rectified by script authors by adding a main function invoked at the end. At a certain point, the argument simply becomes "executing arbitrary code is potentially dangerous", which is trivially true, and also not a helpful security posture for anyone who wants to use their computer pragmatically.
For example, most interactive installers I have seen prompt for install location, and write minimal amount of files outside of it. The chance that they break your system is pretty low.
At the same time, many |bash scrips like to install system-wide packages, or use pip as root, or other potentially breaking things. And they do not ask you before installing this, and often auto-confirm, too.
Re: Please – A cross-language build system
#50Have 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.