4 ms·

I have seen simple things in Open Source Programs that I know I could track down and fix. Off by one errors, modulus stuff and such. Do open source projects ha

I have seen simple things in Open Source Programs that I know I could track down and fix. Off by one errors, modulus stuff and such. Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ? I would be happy to spin up a new VM for every project on that basis.

breck 5y ago
GitPod.io I was waiting for something like this for years, it’s great.
- ghuntley 5y ago
  <3 from the Gitpod team. Yes, indeed condensing CONTRIBUTING.md into a Dockerfile and then offering a single URL to "get ready to code/contribute fixes" from any device, anywhere is exactly what Gitpod is all about. Try it out https://Gitpod.io#https://GitHub.com/gitpod-io/website https://Gitpod.io#https://GitHub.com/gitpod-io/website PS. If you aren't impressed by a JavaScript app then take Kubernetes for a spin! https://github.com/gitpod-io/template-k3s https://github.com/gitpod-io/template-k3s :-)
  - gavinray 5y ago
    Seconding Gitpod, I really wish every repo would take the couple of seconds (to minutes, depending on how complicated) to just create the Docker config for developing it. I use VS Code devcontainers a lot locally, and it's the same concept. This really ought to be something we aspire to as a standard IMO. I've submitted several Gitpod + VS Code Devcontainer setup PR's to projects to spare others the pain of having to figure it out.
  - pnt12 5y ago
    Sounds great, I will definitely try it! One of the latest OSS projects I checked required gcloud and some online account to run make, it wad absurd...
- _carbyau_ 5y ago
  Damn. Minimal figuring out and 50hrs/month for free. As a fulltime working parent, 50 hours a month is more time than I am likely to spend anyway. Awesome. Thank you!
brundolf 5y ago
What I'm talking about is a solution for people who don't even want to know what a "script" or a "VM" is. Allowing them to learn and write only what they would actually need to care about: code.
- cyberpunk 5y ago
  I’m not really sure how one could be w computer programmer without knowing anything about computers…
- adwn 5y ago
  "What I'm talking about is a solution for people who don't even want to know what a "foundation" or "mortar" is. Allowing them to learn and build only what they would actually need to care about: a house." Sounds pretty ridiculous, doesn't it? Why is it that people think that all this computery stuff like syntax and semantics, compilers, and operating systems is superfluous fluff invented by programmers to gatekeep their profession, instead of tools we created to actually do our job?
  - marcosdumay 5y ago
    Well, there is a lot of complexity on them that comes on them that could theoretically be removed, at a pretty reasonable cost. This is the original idea behind IDEs, in that they would come with everything set-up, and you could just jump into the code. But we lost this, maybe because of the web, or the great IDE extinction of the 00's, or the proliferation of non-integrated OSS, or some other thing that happened at the time, and now IDEs are about as hard to configure as a normal build environment.
layoutIfNeeded 5y ago
>Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ? ./configure
- PeterisP 5y ago
  If ./configure just would work for that project out of the box, that would be great, but it seems more like an exception, because usually it's not sufficient and it breaks on some dependency issues that are easily solvable if you know the dev environment and pretty much need mailing list assistance if you don't know how their project works and you just want to fix an off by one error.
- adwn 5y ago
  That's not even close to being accurate. The real workflow looks more like this: 1) Install an appropriate compiler toolchain. 2) Install whatever other tools are needed (like pkgconfig). 3) Install the necessary *-dev packages for the library dependencies. 4) Figure out which options to pass to configure to include the features you want and exclude the features you don't want. 5) ./configure 6) Go back to step 3 because you had a wrong *-dev package version, or you missed a library you care about. 7) ./configure 8) make 9) Diagnose the error messages and scream in frustration, because the compiler you installed in step 1 is too old/too new/too not gcc. 10) Install gcc version x.y.z 11) ./configure 12) make 13) Get the same error messages, because you didn't deinstall the first compiler and configure helpfully selected it again. 14) Give up in disgust and let someone else fix the bug you found.
  - adwn 5y ago
    Sorry, I just realized that the above workflow is wrong: Since you want to fix a bug, you'll probably clone the development branch of the repo, which doesn't even have a configure script – only source releases have that. So prepend these steps: 0.1) Install the autotools. 0.2) Run autoconf, no wait, automake, no wait, autoreconf, no wait, autoreconf --install. 0.3) Delete all files in the directory and checkout a fresh copy. 0.4) autoreconf --install 1) ...
  - 5y ago
taneq 5y ago
Likewise, I've used several OSS projects that I'd be quite happy to fix bugs in or develop new features for, but every single time I've been put off by having to decipher some mostly undocumented or otherwise horrendous build process. Ironically (or perhaps obviously) the OSS projects I've used that have approachable build processes and requirements don't seem to have easily-fixed problems...
adrianmsmith 5y ago
> Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ? I would be happy to spin up a new VM for every project on that basis. Have used Vagrant for that, worked well, but not popular these days. Spins up a VM, you check in a script to install everything you need inside it. Docker Compose isn’t bad for that either. Can specify a bunch of components such a databases, and a Dockerfile can specify what you need in your main container such as particular versions of Java or whatever. Not to say all projects are using these things. But they’re out there, and can be used if the developers want.

breck 5y ago

GitPod.io I was waiting for something like this for years, it’s great.

ghuntley 5y ago
<3 from the Gitpod team. Yes, indeed condensing CONTRIBUTING.md into a Dockerfile and then offering a single URL to "get ready to code/contribute fixes" from any device, anywhere is exactly what Gitpod is all about. Try it out https://Gitpod.io#https://GitHub.com/gitpod-io/website https://Gitpod.io#https://GitHub.com/gitpod-io/website PS. If you aren't impressed by a JavaScript app then take Kubernetes for a spin! https://github.com/gitpod-io/template-k3s https://github.com/gitpod-io/template-k3s :-)
- gavinray 5y ago
  Seconding Gitpod, I really wish every repo would take the couple of seconds (to minutes, depending on how complicated) to just create the Docker config for developing it. I use VS Code devcontainers a lot locally, and it's the same concept. This really ought to be something we aspire to as a standard IMO. I've submitted several Gitpod + VS Code Devcontainer setup PR's to projects to spare others the pain of having to figure it out.
- pnt12 5y ago
  Sounds great, I will definitely try it! One of the latest OSS projects I checked required gcloud and some online account to run make, it wad absurd...
_carbyau_ 5y ago
Damn. Minimal figuring out and 50hrs/month for free. As a fulltime working parent, 50 hours a month is more time than I am likely to spend anyway. Awesome. Thank you!

brundolf 5y ago

What I'm talking about is a solution for people who don't even want to know what a "script" or a "VM" is. Allowing them to learn and write only what they would actually need to care about: code.

cyberpunk 5y ago
I’m not really sure how one could be w computer programmer without knowing anything about computers…
adwn 5y ago
"What I'm talking about is a solution for people who don't even want to know what a "foundation" or "mortar" is. Allowing them to learn and build only what they would actually need to care about: a house." Sounds pretty ridiculous, doesn't it? Why is it that people think that all this computery stuff like syntax and semantics, compilers, and operating systems is superfluous fluff invented by programmers to gatekeep their profession, instead of tools we created to actually do our job?
- marcosdumay 5y ago
  Well, there is a lot of complexity on them that comes on them that could theoretically be removed, at a pretty reasonable cost. This is the original idea behind IDEs, in that they would come with everything set-up, and you could just jump into the code. But we lost this, maybe because of the web, or the great IDE extinction of the 00's, or the proliferation of non-integrated OSS, or some other thing that happened at the time, and now IDEs are about as hard to configure as a normal build environment.

layoutIfNeeded 5y ago

>Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ? ./configure

PeterisP 5y ago
If ./configure just would work for that project out of the box, that would be great, but it seems more like an exception, because usually it's not sufficient and it breaks on some dependency issues that are easily solvable if you know the dev environment and pretty much need mailing list assistance if you don't know how their project works and you just want to fix an off by one error.
adwn 5y ago
That's not even close to being accurate. The real workflow looks more like this: 1) Install an appropriate compiler toolchain. 2) Install whatever other tools are needed (like pkgconfig). 3) Install the necessary *-dev packages for the library dependencies. 4) Figure out which options to pass to configure to include the features you want and exclude the features you don't want. 5) ./configure 6) Go back to step 3 because you had a wrong *-dev package version, or you missed a library you care about. 7) ./configure 8) make 9) Diagnose the error messages and scream in frustration, because the compiler you installed in step 1 is too old/too new/too not gcc. 10) Install gcc version x.y.z 11) ./configure 12) make 13) Get the same error messages, because you didn't deinstall the first compiler and configure helpfully selected it again. 14) Give up in disgust and let someone else fix the bug you found.
- adwn 5y ago
  Sorry, I just realized that the above workflow is wrong: Since you want to fix a bug, you'll probably clone the development branch of the repo, which doesn't even have a configure script – only source releases have that. So prepend these steps: 0.1) Install the autotools. 0.2) Run autoconf, no wait, automake, no wait, autoreconf, no wait, autoreconf --install. 0.3) Delete all files in the directory and checkout a fresh copy. 0.4) autoreconf --install 1) ...
- 5y ago

taneq 5y ago

Likewise, I've used several OSS projects that I'd be quite happy to fix bugs in or develop new features for, but every single time I've been put off by having to decipher some mostly undocumented or otherwise horrendous build process. Ironically (or perhaps obviously) the OSS projects I've used that have approachable build processes and requirements don't seem to have easily-fixed problems...

adrianmsmith 5y ago

> Do open source projects have an obvious "run this script to configure your complete dev environment in respect to this project" ? I would be happy to spin up a new VM for every project on that basis. Have used Vagrant for that, worked well, but not popular these days. Spins up a VM, you check in a script to install everything you need inside it. Docker Compose isn’t bad for that either. Can specify a bunch of components such a databases, and a Dockerfile can specify what you need in your main container such as particular versions of Java or whatever. Not to say all projects are using these things. But they’re out there, and can be used if the developers want.