Code Server (Vs code online)
-
@dswd I can respect the opinion, but I use the addons mentioned as well as the adding different IDEs/SDKs (PS, PHP, Go, Rust, R-Lang, etc etc etc ) as users can't install linux packages on an app once it's installed. I also have build-tools to compile code, and I don't think apache is still there (I ended up choosing to use code-servers built-in proxy instead. So if apache is still being installed I will probably remove it in the future. Sendmail is used for testing and sending email from compiled apps, redis is kept for apps that would require it, and mysql (and other DBs) are thrown in because compiled apps may need a test DB to connect to.
It's kinda bloated when you first look at it, but users cannot modify what linux packages are installed and they cannot modify what cloudron addons are installed once code-server is installed.
That said, yes, technically speaking code-server doesn't need all this, but it's barely an IDE without the ability to actually use the code you write in it. So I included all the popular ones.
Minimal in this case I don't believe works. Sure yours takes up less space but my package includes more features. In this case, I think keeping our apps separated for now is the best course of action.
This is not to say I don't like what you did. There is something to be said about a minimal-first approach to building an app. I think - let's keep building our packages separate and we can talk to @girish / @nebulon about how to add both (potentially) to the app store. Maybe just labeled differently so the admins can choose how they like to build.
And if we do go that route I would like to work together to make the login process the same on both apps - to help make it seamless to the end-users.
What do you think? I am also open to suggestions.
Edit: I hope none of this comes off as negative towards your package. That is not my intent. It's clear you and I both have a want/need/passion for code-server to be on the store. I am just genuinely excited to have this conversation with someone other than myself.
-
@murgero
I can see your point. You are providing those dependencies to users just in case they need them (and because you need them). I agree, not being able to install packages is kind of a problem. However, a lot of software (e.g. nodejs, rust and php) can be installed into the user space.
I decided against putting in more dependencies because I don't want to monitor so many dependencies for security issues and push new releases every other day.
I too think it would be best to keep the versions separate as you require those dependencies.
Oh and no, your comment does not come off as negative (hope mine doesn't either). We just have different approaches. -
@murgero
I think I found a way to get around the read-only root and install additional software. I added a script that will fetch and install a minimal Linux and chroot into it:chroot-alpine.
Inside it you can install additional software as you like. You can also use the same method to run Ubuntu instead of Alpine Linux but that will use much more storage. -
I think we should collaborate on a minimal base docker image that only contains the installation of code-server, and then design a solution to allow adding dev dependencies on top of it as required by each end-user.
Say, first lift all the code-server-specific improvements from murgero's image into dswd's image and publish it at
cloudron/code-server-base. Then murgero's image starts withFROM cloudron/code-server-baseand adds their unique dev dependencies and publishes it separately. The key will be improve the image build, installation, and updating process to be as smooth as the usual app install process. (The cli is great for cloudron development, but kinda cumbersome for ongoing maintenance.)Based on the way code-server is designed I doubt it could ever be a multi-user app. There is some discussion on code-server multi-tenancy on Setting up code-server for multi-tenancy #792. In summary, it doesn't seem viable and the discussion quickly shifts towards how to set up and manage a container-per-user design, which is an area that I think Cloudron could add a lot of value.
Perhaps both of these problems could be solved by creating a custom app that uses the cloudron api to expose an easier way to spin up code-server apps for users on demand, using the images designated by the admin.
code-server is a good use-case for proxyAuth. I think it would be neat if we could forward some path to a port inside the container to allow users to hit a dev web server running inside.
-
@infogulch said in Code Server (Vs code online):
I think it would be neat if we could forward some path to a port inside the container to allow users to hit a dev web server running inside.
code-server natively supports this already, just simply logging in and then browsing to
https://fqdn-of-app/proxy/portNumberexample:https://vscode.example.com/proxy/8080would put you on port 8080 inside the app. So if you had an app or something running on that port, it's http data would be displayed like normal. -
@murgero said in Code Server (Vs code online):
code-server natively supports this already ...
https://fqdn-of-app/proxy/portNumberOh neat, I'm glad they landed on that, that's a good solution. Perhaps a proxyAuth implementation should exclude the proxy path with something like
"proxyAuth": { "path": "!/proxy" }.Perhaps this is a bit to early to worry about, but at some point we might consider restricting the app proxy's access to cloudron cookies with domain or path parameters.
-
@murgero @dswd what are the extra packages that are pre-installed? If it's not too big, maybe we can compromise and just install it all in one. It's more important to be useful to more number people than be minimal (of course, everything has a limit..).
I wonder if the right approach here is something like JupyterHub. What that project does is to have a "workspace manager" with a login screen. When logged in, it spins up a new "notebook docker container" for each user. This way the user can install whatever packages they want in that docker image. See https://github.com/jupyterhub/jupyterhub . I guess in our case if the size is limiting, maybe we should write a VsCodeHub which when logged in, spins off a vs code container for each user. This makes the app properly multi-user.
-
My package includes a ton of extra packages to cover the most popular programming and scripting choices. (Some are actually already in the Cloudron base image, which I use.)
- GOLANG
- PHP7.4 (PHP8.0 will be included soon!)
- Python
- PowerShell
- DotNet Core (C#, VB.NET, etc) (.NET Full will be included soon as well since full supports Linux now I believe)
- R
- R-lang
- NodeJS (Updated to latest)
I am probably missing a couple but I wanted to make sure a lot of the popular stuff was covered here.
-
-
-
-
@enabl-ist was curious if this is related to "code server", but it seems to be something newly done without any relations to the existing project.
https://github.com/cdr/code-server/discussions/4267
similar discussion in the "openvscode" project https://github.com/gitpod-io/openvscode-server/discussions/99
-
@fbartels indeed it looks like two different projects, with (kind of) the same goal... What I read is that the gitpod version is more simplified in features. I haven't had time to test it myself, just wanted to let the community know of this similar project.
