Last Thursday, Telescope 2.7 landed, and I think it is one of the biggest releases yet on Telescope, with over 83 addressed items! This includes issues and PRs in a single category.

What was included?

This release included a big step forward in two areas: documentation and Supabase.

Recently, the Telescope team was planning on moving most of the architecture to use Supabase. If you don't know what Supabase is, it is very similar to what Firebase does but with a more open-source approach.

Really hard work has been done by @dukemanh to ensure that we can start using the Supabase infrastructure in the sso (single-sign-on) service of Telescope, and while there are still some wrinkles to iron out, we are almost there!

Regarding documentation, there has been a lot of work from several people in Telescope, as well as from new contributors. We chose Docusaurus as our main documentation generator, mainly for the experience that several people in the team have with the tool.

What did you do for the release?

Most of the contributions that I landed were small contributions that fixed a few issues, nothing related to a big project.

Well, there were a couple of PRs related to the dependency-discovery, focused on converting it into a docker container. The dependency-service is now live! It is very small, I know, but we all have to start from somewhere!

Any other interesting things going with Telescope?

So, lately, I've been trying to slowly migrate the development environment I have for Telescope from my laptop to my main desktop computer. I preferred my desktop computer for developing, as the screen is much bigger and I can fit several things at once.

The thing is, it is somewhat of a challenge, since my laptop is a dual-boot machine (Linux and Windows), while my desktop computer is a single-boot machine (Windows only), and most of my development environment is in the Linux part. Of course, I installed WSL and stuff, but I am planning for something a little bit more.

You see, when I have a clean environment, I would like to keep it organized and not pollute the global environment when installing things. This is somewhat difficult, since the regular way of installing software in Linux is through a package manager that handles the dependencies for you. This is useful and all, but most package managers do not have a concept of keeping environments isolated from each other.

Why is this a problem? Let's say that you depend on a specific program, docker, and you have a specific version that you know it works. Then, you start to work on a new project, and you would like to install a new version of docker that has certain new features. The moment you install a new version of docker, the old version gets overridden, so now you have to keep track of all the versions of docker that your programs may depend on.

Well, instead of keeping track of things manually when we already have computers, that automate so much for us, there should be a way to automate this, right? Well, there is! Enter nix, a package manager which its main purpose is to keep your builds reproducible by isolating the environments themselves.

Wait, what? Reproducible builds by isolating environments?

If you are not really sure what I mean by a reproducible build, it means that if I run a process to build a program, I should be able to take the exact same codebase, run the exact same process in another computer, and get the exact same build I got before as a result. This might be difficult to get right, especially when you have a global state that could influence the build process.

This is where the second word comes in, 'isolating'. Instead of trying to come up with a complicated scheme to separate the environments, nix manages the global environment so that it fits the environment necessary for the build process (by global environment, I refer things like the environment variables of the shell).

I won't explain deeply how nix accomplishes this, since this would be the topic of another blog. However, I would like to mention an interesting application of nix. Since we can isolate build environment, this may also mean that we can isolate the development environment of such project.

Indeed, one of my main objectives to migrate the development environment from my laptop to my desktop is building a nix template that describes the necessary dependencies to have an isolated development environment.

Sounds cool, but how are you going to do it?

Well, the main challenge is to discover exactly all the dependencies that Telescope uses. With dependencies, I include not only the JavaScript dependencies used by the project, but also tools that we use, like docker, node, npm, pnpm, etc.

I also need to figure out how nix would allow something like this, since the main purpose of nix is creating a build environment that can be isolated. Since Telescope does not get built in the traditional sense of the word (that being something like compiling).

It is going to be an interesting challenge. I will try to document that steps I took