Add devfile to develop Theia in Che

[vzhukovs]

What it does

This changes proposal provides workspace configuration file which sets up Che environment to develop Theia. This configuration is represented as devfile.

For the detailed explanation of all devfile components assignment and possible values, please see the following resources:

• Specification repository
• detailed json-schema documentation.

Signed-off-by: Vladyslav Zhukovskyi vzhukovs@redhat.com

How to test

The simplest way to use devfile is to have it deployed into GitHub source repository and then create factory from this repo.

https://<your-che-host>/f?url=https://github.com/vzhukovskii/theia

Also, it is possible to execute devfile by constructing the factory with the URL to it's raw content, for example:

https://<your-che-host>/f?url=https://raw.githubusercontent.com/vzhukovskii/theia/master/devfile.yaml

If you're a user of chectl tool, it is also possible to execute workspace from devfile, using workspace:start command parameter as follows:

chectl workspace:start --devfile=https://raw.githubusercontent.com/vzhukovskii/theia/master/devfile.yaml

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[svenefftinge]

I’m obviously biased, but since we have a well-working solution for this, I’d vote for closing this PR. I understand that some of the RedHat contributors might want to use their own tool for dogfooding reasons, but for the general community maintaining two solutions for the same problem doesn’t help.

Also, it is possible to execute devfile by constructing the factory with the URL to it’s raw content, for example:
https://<your-che-host>/f?url=https://raw.githubusercontent.com/vzhukovskii/theia/master/devfile.yaml

Sounds like a great solution that allows you to maintain the config file externally.

@marcdumais what's your take on this?

[paul-marechal]

but for the general community maintaining two solutions for the same problem

Kind of a stretch since so far the Gitpod files are only maintained by TypeFox:

• https://github.com/eclipse-theia/theia/commits/master/.gitpod.yml
• https://github.com/eclipse-theia/theia/commits/master/.gitpod.dockerfile

The fairest solution to me would be to make both Gitpod and Che configs external and have a button for both in the readme?

[akosyakov]

Kind of a stretch since so far the Gitpod files are only maintained by TypeFox:

General community is not maintainers of Gitpod files, but people who trying out Theia. Confusing them with multiple configurations files for different tools for the same purpose does not sound good.

[akosyakov]

devfile.yaml

Putting a configuration file with such generic name in the repo root does not look good to me.

[gorkem]

Gitpod is a product, Che is an open source project on Eclipse foundation, just like Theia. I think rejecting Che's artifacts while accepting gitpod is not fair. We should have either both or neither.

[marcdumais-work]

Gitpod files are only maintained by TypeFox

In the interest of fairness, I'll point-out that we (Ericsson) have added the Gitpod config to the theia-cpp-extensions repo. We did so not because we want to take sides but just because it makes our life so much easier.

[tsmaeder]

Tbh. the interesting thing here is not where the devfile lives, but what the button in the Readme.md points to, so plus one on not hosting it in the Theia repo (btw: could we do this for the gitpod.yml as well?)
As a Red Hatter, I rail at the outrage of not having Che as an option (😉), but as a Theia committer, I really don't care.

So my proposal:

• host both gitpod.yml and devfile.yml outside of the Theia repo
• add a button for Che (or not)

[vzhukovs]

For us it also important to have an ability to open workspace as fast as possible with configured environment. With this devfile it can be performed in one click, because all information can be fetched from this repository.

[azatsarynnyy]

I'd look at it from the perspective of diversity.
Different contributors are working on Eclipse Theia using different tools, e.g. VS Code, Gitpod, Eclipse Che. There are not many. So, why not store the related configs within the repo and make it more welcoming for the new contributors.

[marcdumais-work]

We had a rather heated internal debate about this but could not come-up with a good, nuanced and fair solution. Some elements:

• We agree that it does seem unfair to allow in our repos one service's / project's config and not another one
• Right now we're talking Gitpod and Che, but others will surely come knocking at the door expecting to be granted the same "fairness"
• Only two extreme solutions seem to be fair in the long run, but neither seems very satisfactory: permit or deny all such inclusions

[bmicklea]

@marcdumais-work I agree with your sentiment, especially that others will come knocking. But I'm unclear on why allowing or denying all seems unsatisfactory. Can you explain?

[akosyakov]

Gitpod is a product, Che is an open source project on Eclipse foundation, just like Theia. I think rejecting Che's artifacts while accepting gitpod is not fair. We should have either both or neither.

The point was not about fairness of promoting one tool or another. There was an issue to make it easy to try and contribute to Theia. It was already resolved by putting effort into developing and streamlining Gitpod particularly for this repo. Nobody is arguing to add Circle CI when you already have Travis get you covered, or have neither. (both not Eclipse products btw) Introducing another tool just make it confusing, i.e. which config is used to configure what tool? What should I click to try Theia? how to maintain it when we add native tool? If TypeFox always add such tools, how to keep other config files up to date? and so on.

We have all these streamlined already. Why should we disturb it now?

For us it also important to have an ability to open workspace as fast as possible with configured environment. With this devfile it can be performed in one click, because all information can be fetched from this repository.

Looking at comments and upvotes above it does not seem to be goal of this PR. Otherwise it can be resolved by external configuration.

[ghost]

@akosyakov the logic of having a vendor-neutral framework is not favoring any of the commercial products consuming it over any other. Making a statement on the front page of the project that this vendor-neutral project works best/is developed best with commercial product A doesn't sound too neutral.

It is neutral either if you don't do it at all or if you say it works with A, B, C and D so pick whatever you prefer.

[marcdumais-work]

@marcdumais-work I agree with your sentiment, especially that others will come knocking. But I'm unclear on why allowing or denying all seems unsatisfactory. Can you explain?

I think allowing any/all config will clutter the repo but as well it seems we'd lose the practical ability to judge each proposed config according to the value it adds to the repo/project.

Having no config at all would probably work as long as they're still practically available outside the repo. I expect then that the discussion will move-on to other related aspects like the badges, CI integration and such, with likely the same conclusion in the end - remove them all. In this scenario I think developers coming to this repo will lose-out by not being made aware that there are Theia-based options to make contributing easier, even if there are other ways to trigger the services.

[benoitf]

I think that any free hosted IDE could add links as long it's made on top of Eclipse Theia.

Also I could argue that gitpod is limiting the number of hours per month.

[akosyakov]

Making a statement on the front page of the project that this vendor-neutral project works best/is developed best with commercial product A doesn't sound too neutral.

Could you point me to such statement where we say that Theia works the best with Gitpod in this repo or website?

It is neutral either if you don't do it at all or if you say it works with A, B, C and D so pick whatever you prefer.

True, users are up to explore any solutions. We try to mention all adopters in marketing materials about Theia including Che.

As I said it is not about marketing to me, but concrete use cases simplifying trying out Theia, maintaining and contributing to this repo. As the most active maintainer I've spent time configuring all these stuff, making it good and maintaining as well. Caring for all kind of PRs and applications. How can I be sure that whatever we add will be of the same quality If I'm not going to maintain it? How can it help me if i am not going to use it?

I agree that there are use cases for Che contributors for dogfooding and actually I'm glad that they use Theia to develop Theia, but it does not require config files in this repo.

[bmicklea]

That kind of control by a very limited number of users is how Microsoft controls VSCode and was a big part of why Theia and OpenVSX were created. To simply change who the limited number of people are who have all the control doesn't do anything to justify Theia over VSCode.

An open approach is what will be needed to keep the Theia community strong. Why wouldn't we start by including all and, if things get too cluttered, consider other options? None of this is carved in stone :)

[vince-fugnitto]

For my own understanding and information, how would including the che configuration in the repo help me as a maintainer of the project, or for a new contributor?

[gorkem]

@vince-fugnitto Does your argument assume that the originator of this PR is not a maintainer or a contributor to this project?

[vince-fugnitto]

@vince-fugnitto Does your argument assume that the originator of this PR is not a maintainer or a contributor to this project?

@gorkem no of course not, just asking in general how useful/how much value the config brings for all types of devs (maintainers, new contributors, etc). I'm mainly interested in understanding how adding the configuration will benefit the overall community.

[paul-marechal]

There was an issue to make it easy to try and contribute to Theia. It was already resolved by putting effort into developing and streamlining Gitpod particularly for this repo.

Gitpod does fix the "how to allow any developer to easily contribute to Theia's repository" issue indeed. I used to not pay too close attention to the different Gitpod integrations that were added, but I agree with the argument that it currently solves the "making contributions easy" issue. I just don't remember discussing using Gitpod to address this problem specifically. So unless someone wants to propose a better tool or thinks we don't need such a tool, I'm fine with how things are.

However, I think it would be really nice to add a readme section with a list of Theia-based services that someone can use to edit the repository.

Something like:

---

Contribute to Theia using a Theia-based service!

• Gitpod:
• Che on OpenShift:

---

Or maybe just add the Che badge directly with all other badges, I don't see the harm.

And have metadata for services that we don't actively use in our repo being stored externally.

[akosyakov]

An open approach is what will be needed to keep the Theia community strong. Why wouldn't we start by including all and, if things get too cluttered, consider other options? None of this is carved in stone :)

I agree here, there are very good RedHat engineers and it will be a pity to not work with them. But I still don’t like the fact of having a file named devfile.json in the project root (it is not tool specific at all) and have fears that it will get outdated, not maintained, or give bad first experience. I think we will discuss internally and then on the next dev meeting to decide what should be done to accept this PR.

That kind of control by a very limited number of users is how Microsoft controls VSCode and was a big part of why Theia and OpenVSX were created. To simply change who the limited number of people are who have all the control doesn't do anything to justify Theia over VSCode.

I don’t think it is fair. We tried to contribute to LSP and were not successful because VS Code team always want everything available in VS Code first, so much for standards. For Theia, I had to do the opposite by chasing and convincing RedHat engineers to review my PRs which not immediately necessary in Che. We also accepted everyone, consider their opinions, reviewed their PRs, and fixed stuff afterward often not pressing or unrelated for Gitpod. I personally went to RedHat engineers while working on webviews to make sure that interesting for them VS Code extensions are working, explaining web security, and so on. For users, we maintained vendor-neutral docker images where nobody but Ericsson helps. We gave credits for contributions and mentioned adopters in our materials regardless of our Gitpod strategy. Talking about openness and fairness above, I don’t think anyone was so fair and open to us.

Each project needs limited number of people to define the architecture, promote, and maintain it integrity. I don’t think it should be justified and means not being the vendor-neutral. Because of it, we have Theia and Open VSX now.

[marcdumais-work]

That kind of control by a very limited number of users is how Microsoft controls VSCode and was a big part of why Theia and OpenVSX were created. To simply change who the limited number of people are who have all the control doesn't do anything to justify Theia over VSCode.

IMHO nothing we are discussing here can be compared to Microsoft's control of VS Code (their project so they're free to do whatever). I'm aware of technical discussions about where something should be done (theia or che), but I've never felt the goal was to artificially disadvantage Che, or prevent Che from openly competing with alternative products/services, just to maintain a sane level of separation-of-concerns. To the contrary I remember the occasional small accommodation made for Che.

[gorkem]

I agree here, there are very good RedHat engineers and it will be a pity to not work with them.

I do NOT think Brad is saying that Red Hatters will stop contributing to this project. We have not done this even on worse things that offended Red Hat contributors.

But I still don’t like the fact of having a file named devfile.json in the project root (it is not tool specific at all) and have fears that it will get outdated, not maintained, or give bad first experience. I think we will discuss internally and then on the next dev meeting to decide what should be done to accept this PR.

Same argument can be done for any file including the gitpod one or .vscode files that are strangely still at the root of the repo and does not seem to bother anyone.

We gave credits for contributions and mentioned adopters in our materials regardless of our Gitpod strategy.

You do realize bad mouthing your adopters does not count as mentioning :)

Each project needs limited number of people to define the architecture, promote, and maintain it integrity. I don’t think it should be justified and means not being the vendor-neutral. Because of it, we have Theia and Open VSX now.

Who are those limited number of people for Theia? Are they listed anywhere?

[ghost]

@akosyakov you are making a clear statement right here in this PR - and in your master branch - and in your README.MD which suggests gitpod as a commercial product is the way to go if you want to develop Theia through the first badge you see under the title. And when other open source projects offer themselves as being an alternative there is this pushback that - no, GitPod is already working so please go away. And this is not some people with no merit approaching you with an alternative but fellow contributors that have alternative tooling to your commercial offering.

Making a comparison with Travis CI or other tooling you use is naive at best and misleading at worst. The vendor-neutral credential is what is at stake here, and we're talking about not favoring any tool - commercial or not - that consumes this vendor-neutral project.

How can I be sure that whatever we add will be of the same quality If I'm not going to maintain it? How can it help me if i am not going to use it?

I find it very discouraging overall that you're saying here that as the most active maintainer you want everything that goes in to be up to you to maintain and comply to your wishes, and that it should help you, personally. This is really not about you. If you care about a certain alternative you're free to take care of it. If other maintainers, second- or third-active want to maintain another alternative they should have equal rights to do so. If they can't, you can't as well. This kind of more equal among equals mentality is not going to help.

[akosyakov]

I like @marechal-p proposal, but I don't think anyone will come knocking and we need a list of services, another badge will do?

[ghost]

@marechal-p just to clear this up for myself, you're proposing to add the badges on the readme but host the config files of any service except GitPod externally?

[akosyakov]

@scela @gorkem There are fundamental decisions like architecture, coding standards and so on. Including that we want to keep our setup clean and small. We had strong discussions over smaller tools, like to use the simple npm scripts setup over gulp or how to hide as much as possible in config folder. Letting everybody pushing and maintaining what they want disregarding such decisions bloat the project and dilute its goals. Saying NO often to keep integrity is not different for other open source projects. By limited number of people I mean maintainers who internalised such fundamental rules very well and can guide others to adhere them. Theia is not a simple project with 2 adopters.

I do realize that Che is not any other tool, but something like devfile.json in the project root does not go well with project conventions. At least it should be named clearly that it relates to Che or go under config/che folder. If it is fine to be external then a badge will do too.

[ghost]

Could you reference which specific project convention is being crushed by having a file named devfile.json in the repo?

[akosyakov]

Could you reference which specific project convention is being crushed by having a file named devfile.json in the repo?

@scela I mean simply we will have 2 dev environments. It will confuse anyone who wants to look at Gitpod or Che configuration files where to look. It should be clear.

Not everything is written down, something was discussed at some point on comments in some PRs. We try to document thought and if you think it should be written down file an issue with documentation label.

[ghost]

Well you already have .vscode at the root and that doesn't seem to be upsetting any convention.

[akosyakov]

Well you already have .vscode at the root and that doesn't seem to be upsetting any convention.

I don't know how it is related. .vscode clearly relates to VS Code and there to test preference compatibility of mixing/merging values from .theia and .vscode folder.

[ghost]

It is related in the sense that if you're eyeballing the folder you could be confused in equal measure on about there being two dev environments and which to choose.

Of course if one clicks and sees the content it all clears up fast but that's true for the devfile as well.

[svenefftinge]

I think there are two different angles this should be discussed from.

The first is the perspective of an open-source project that uses a certain service to make development easier. This is in the same light we use other services such as a CI system. It just helps and is very useful. We at TypeFox have done most of the development in Theia using Gitpod, and we have seen many PRs from others coming through Gitpod, so it's just practically super useful for the project. My earlier point was that for users it is not beneficial to have to make a choice when starting contributing. For the same reasons we would not add many different CI systems, because it adds additional complexity to the project.

The second aspect is to use the project as a marketing instrument for downstream services. I feel like most of the arguments exchanged above were made from that perspective. As TypeFox, a strong association between the work we have done on the Theia project with the business we are building around Gitpod is of course helpful. Since we initiated the project and have written a lot of the code, I think it is fair to leverage this a bit, especially considering the relative size of our company. That said, the success of the project and its vendor-neutral nature is more important and since RedHat has contributed a lot as well, it is fair if they insist to have an exposure for the openshift service in the same way.

Again, I feel the first aspect should dominate in our decisions here, but I'd be happy to compromise a bit because of the active and longterm contributions from RedHat. OTOH I'd not want to add more such alternatives in the future. But since we don't have any meaningful contributions from people working on similar services, we should be ok with this.

[vzhukovs]

Hopefully there is a soothing light in the end of this tunnel.

I think, it will be fair to hear also @marcdumais-work opinion.

[sunix]

Thanks @svenefftinge,
I think that it is good if this project benefits all the community. It has to be win-win for everyone. We need to respect each other and work together to make Theia a great opensource project.

Red Hatters have not initialized this project but have made valuable contributions to Theia. This PR is not even promoting a Red Hat closesource commercial product but a Eclipse opensource project that embeds Theia ... so it should be fine. Thank you.

[paul-marechal]

@scela yes, I suggested to keep Gitpod's configuration files since it is a tool "actively used by the project" to facilitate contributions, and keep Che's configuration external since the goal will solely be to promote it and not to maintain it. Please tell us if you had something different than promotion in mind.

@scela @gorkem for the .vscode case, I'd like to argue that we can expect people to keep doing contributions with the most popular IDE for TypeScript development. It used to be the recommended development tool for Theia, and I don't think we can really expect everyone to now exclusively use Gitpod instead, hence both configurations. (I also still like to use VS Code)

[marcdumais-work]

Thank you Sven - you have a gift for untangling such a discussion and extracting the essential elements. Like you I see the benefits of compromise and I am ok with the outcome.

I am however not totally happy about how parts of this discussion unfolded. I think every project committer owes special thanks to Anton and should be glad we have someone like him working with us and making sure the overall project stays on course. To be clear, no one is above critic or scrutiny and it's good that we get to talk openly and transparently, as happened here.

Eclipse Foundation projects are based on four principles - we touched upon Vendor Neutrality in this discussion, but another important one to keep in mind is Meritocracy, meaning that those who contribute more have the right to decide more as well. I know of no one who did and does more for this project overall than Anton - Just look how omnipresent he is in project issues, PR reviews, Spectrum support. The git repo stats reflect this as well (*). We should value and be thankful for any and all contributions, even more so when they're so demonstrably substantial.

(*)

Open this link in Gitpod to see a live version of the repo stats (sorry, I did not have time to test in OpenShift ;):
https://github.com/marcdumais-work/gitstats