4 ms·

I’ve very recently become a GitHub engineer, and I got pre-access to the beta too and I must say - my absolute favourite thing about CoseSpaces is being able to

I’ve very recently become a GitHub engineer, and I got pre-access to the beta too and I must say - my absolute favourite thing about CoseSpaces is being able to dev on a repo you don’t work on regularly and probably wouldn’t contribute if it meant having to set up environment etc. It’s really nice to just dip into a project with a working environment in seconds, make your PR and then move on.

mynameisvlad 5y ago
This was my first idea for introducing Codespaces to my team -- set up the infrastructure to be able to spin up a codespace on our less-used component repos where people don't have a local dev environment prepared.
deleted 5y ago
[deleted]
miohtama 5y ago
How does it work when you work on several packages at once,e.g. a lib and an app using it? Is it a monorepo, do you configure both dependencies to be locally editable copies, etc.? For example patching an upstream open source project that is a blocker for your app.
- dcreager 5y ago
  The codespace is backed by a regular Linux VM, so we can clone the upstream repo and edit/compile/debug/etc in that just like we would locally on our laptops and workstations.
- dcreager 5y ago
  You can also create a separate codespace for each package if they’re independent of each other and you don’t need to test things in the downstream repo in a way that requires your changes being available “locally”.
lilyball 5y ago
This is a problem that can be solved without Codespaces too. For example, if GitHub were to embrace Nix, every project could have a shell.nix file for all of their dependencies, and the new engineer bootstrap script that installs Nix could then just add an internal Nix binary cache (or use Cachix). Any time the shell.nix changes a GitHub Action could push the closure to the binary cache. With this setup, you can use whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you. The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it. Unfortunately most companies still aren’t paying any attention to Nix.
- stnmtn 5y ago
  -insert comment about that hacker news comment about how dropbox could be replicated with linux here-
  - neilparikh 5y ago
    I'm not sure that comment applies here. The suggest Dropbox replacement was more complicated than Dropbox, and had more steps. On the other hand, Nix is about the same amount of complexity, and same number of steps for the developer. Yes, the parent comment looks a bit complicated, but that's just the one time setup, not something that needs to be done by every developer. And Codespaces will require some of that setup too; it's not like it'll magically know what packages and dependancies your project requires to build.
  - syspec 5y ago
    - I see comment about iPod, no wireless, less space than a nomad. lame
- imron 5y ago
  Does it take 10 seconds to spin a new one up? If not, then it misses the main benefit outlined in the article.
fortyrod 5y ago
I'm a big fan of capturing the toolchain(s) with the repo. I have had to hack this for embedded toolchains out of necessity for years (decades?) using VirtualBox on a Mac. I still have a Windows 95 VM sitting around containing a copy of Keil or something that is the only known way to rebuild the code for a certain weird-ass micro from some consulting gig in the late 90's. I wonder if it still boots? Hopefully, that customer forgot about me...
wnevets 5y ago
> . It’s really nice to just dip into a project with a working environment in seconds, make your PR and then move on. That sounds incredibly useful actually. Is that the main sales pitch for codespaces?
- sammorrowdrums 5y ago
  Well I use them for regular dev in work too on especially larger repos with heavier toolchains, and both are big plusses for me personally!

mynameisvlad 5y ago

This was my first idea for introducing Codespaces to my team -- set up the infrastructure to be able to spin up a codespace on our less-used component repos where people don't have a local dev environment prepared.

deleted 5y ago

[deleted]

miohtama 5y ago

How does it work when you work on several packages at once,e.g. a lib and an app using it? Is it a monorepo, do you configure both dependencies to be locally editable copies, etc.? For example patching an upstream open source project that is a blocker for your app.

dcreager 5y ago
The codespace is backed by a regular Linux VM, so we can clone the upstream repo and edit/compile/debug/etc in that just like we would locally on our laptops and workstations.
dcreager 5y ago
You can also create a separate codespace for each package if they’re independent of each other and you don’t need to test things in the downstream repo in a way that requires your changes being available “locally”.

lilyball 5y ago

This is a problem that can be solved without Codespaces too. For example, if GitHub were to embrace Nix, every project could have a shell.nix file for all of their dependencies, and the new engineer bootstrap script that installs Nix could then just add an internal Nix binary cache (or use Cachix). Any time the shell.nix changes a GitHub Action could push the closure to the binary cache. With this setup, you can use whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you. The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it. Unfortunately most companies still aren’t paying any attention to Nix.

stnmtn 5y ago
-insert comment about that hacker news comment about how dropbox could be replicated with linux here-
- neilparikh 5y ago
  I'm not sure that comment applies here. The suggest Dropbox replacement was more complicated than Dropbox, and had more steps. On the other hand, Nix is about the same amount of complexity, and same number of steps for the developer. Yes, the parent comment looks a bit complicated, but that's just the one time setup, not something that needs to be done by every developer. And Codespaces will require some of that setup too; it's not like it'll magically know what packages and dependancies your project requires to build.
- syspec 5y ago
  - I see comment about iPod, no wireless, less space than a nomad. lame
imron 5y ago
Does it take 10 seconds to spin a new one up? If not, then it misses the main benefit outlined in the article.

fortyrod 5y ago

I'm a big fan of capturing the toolchain(s) with the repo. I have had to hack this for embedded toolchains out of necessity for years (decades?) using VirtualBox on a Mac. I still have a Windows 95 VM sitting around containing a copy of Keil or something that is the only known way to rebuild the code for a certain weird-ass micro from some consulting gig in the late 90's. I wonder if it still boots? Hopefully, that customer forgot about me...

wnevets 5y ago

> . It’s really nice to just dip into a project with a working environment in seconds, make your PR and then move on. That sounds incredibly useful actually. Is that the main sales pitch for codespaces?

sammorrowdrums 5y ago
Well I use them for regular dev in work too on especially larger repos with heavier toolchains, and both are big plusses for me personally!