Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] About versions of Che 7 plugins and editors


I have a slight improvement suggestion. When defining plugins, it should be possible to define a tag like “latest” which should be the default. We can
interpret empty version number as “latest” as well. Asking this because somewhere down the line I would like to support the tag “next” (similar to npm)
as a way for plugins to publish to early adopters and testers etc.



Thanks,
Gorkem

On 26 Dec 2018, at 2:39, Sergii Kabashniuk wrote:

Today I've talked with Yevhen Vydolob. He told me that all plugins( Theia or VsCode) 
transitive dependencies are packaged with the plugin and not mixed with over plugins 
dependencies in runtime.

According to this  range of versions for Che editors/plugins is quite a safe feature
with "Not transitive dependencies" constraint.

On Sat, Dec 22, 2018 at 2:59 PM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
Alexander - the way you are answering to me become looking like you are not telling the whole story or trying to avoid the answer. 
If the issues raised by me not exist just tell me your argument why you think they do not exist,
if you don't know or not sure - let someone else answer
may be Florent or Yevhen Vydolob can clarify it. 

Your attempts to send me in other thread look disrespectful or even rude.


On Sat, Dec 22, 2018 at 2:39 PM Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> wrote:
I DO think that transitive dependencies are important, I just don't think it is the same topic that Mario started here.
The difference is that what Mario is describing needs to be part of Che master logic and you are describing something that is not in our model of che-plugin.yaml.
I would suggest you start another email thread about adding this feature to Che 7.
Also, I think that Mario's topic is more important even for Che 7 beta and yours is more important for the Che 7 stable release.
Since we have limited time to deliver beta if we want to be on time we should consider which of these two topics to include into beta and which into stable milestones.

On Sat, Dec 22, 2018 at 1:36 PM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
It is the same topic and I want to clarify it.
If your answer for Q1 an Q2 would be  - Eclipse Che plugin mechanism 
doesn't have transitive dependencies lets clarify it for all types of plugins.
For Che editor or Che plugins that are packaged inside of containers 
- a container is protection/isolation. If editor/plugin 's authors are not doing stupid things
like deleting container then we are good.

Now let's talk about the plugin that is not containers - Theia and VsCode.
AFAIK they are(can be) delivered to some(single) container with broker mechanism. Are they packaged
with all transitive dependencies in a single, isolated bundle and running as an individual isolated process?
Why I'm asking. Imagine I'm an author of some stack. 
Let's call it "Enterprise 1"
plugins : TheiaPlugin1:V1, TheiaPlugin2:V17
I've tested it - everything goes well. Now I start selling it.
Am I protected from Q1 and Q2 at this use-case?


Q1: "npm left pad chaos" protection
Q2: reproducability.

On Sat, Dec 22, 2018 at 11:06 AM Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> wrote:
I think it is another topic and don't want to hijack the current one.

On Sat, Dec 22, 2018 at 9:11 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
Is that relevant for Theia and VsCode plugins? Is there any kind of plugin process isolation?

пт, 21 груд. 2018, 20:19 Oleksandr Garagatyi користувач ogaragat@xxxxxxxxxx пише:
We haven’t implemented transitive dependencies if you mean that. 

пт, 21 дек. 2018 г. в 19:39, Sergii Kabashniuk <skabashn@xxxxxxxxxx>:


On Fri, Dec 21, 2018 at 7:23 PM Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> wrote:
Mario suggested usage of strict version for that. 
If this is so needed we could also add configuration to Che master to forbid non-strict version usage, but it doesn't seem that needed for me.
 
This is a good answer for first level dependencies. 
What about a third and others? Are we going to provide some kind of plugin.version.lock file that will list the whole chain of dependencies like [1]-[3]?

Practical example:
My workspace:
 plugins: p1:v1(strict)
 
p1 has strict dependency d2
d2 has dependency d3 with a range of version x.(?)
How can I protect myself from braking changes in dependency d3?





On Fri, Dec 21, 2018 at 7:19 PM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
I do like the power that these features provide, providing them we need to make
sure we have proper answers for some non-obvious circumstances like:
- I'm an enterprise customer with high SLA requirements.
   How I can make sure that plugins that I'm used are not affected by "npm left pad chaos" [1].
   Shortly speaking how can I can protect myself from breaking changes that
authors of transitive(first-second -..... level) dependencies can make.
- Reproducible workspaces are no longer guarantee for 100%, but what If I want?


WDYT What would be your answer for this?


On Fri, Dec 21, 2018 at 3:02 PM Stevan LeMeur <slemeur@xxxxxxxxxx> wrote:
Thanks mario for summarizing.

Works for me too.

On Fri, Dec 21, 2018 at 2:01 PM Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> wrote:
+1 to proposed case 1 and 2 solutions. 
And even if version range for a plugin would be interesting for the community we could add this feature later.


On Fri, Dec 21, 2018 at 2:10 PM Mario <mario.loriedo@xxxxxxxxx> wrote:

An initial discussion about Che 7 plugins versions was started on https://github.com/eclipse/che/issues/12168. It's an important topic and I would like to bring it here to reach more people.

The questions are quite simple:

1. when defining the plugins of a workspace, should a user specify a particular version? no version at all? a specific range of versions (e.g. using ~ and ^ npm annotations)

  - name: exec-plugin
    type: chePlugin
    id: che-machine-exec-plugin:0.0.1

2. and what about when, in a plugin definition, the maintainer of the plugin need to specify the editors compatible with the plugin (e.g. theia)? Should he specify the compatible versions of the editor as well? What about a range of versions?

editors:
  - id: org.eclipse.che.editor.theia:1.0.0

I think that for case 1. we should support:

- no version (defaults to latest version of plugin, that's what most of the people that try Che for the first time want)

- specific version (that's for people that look for reproducible workspaces, one of Che promises)

For 2. we should support:

- no version (the plugin is compatible with whatever version of Theia Che is using)

- a range of versions (using ~ and ^ the npm way)

Mario

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

OLEKSANDR GARAGATYI

SENIOR SOFTWARE ENGINEER

Red Hat 

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Stévan LeMeur // Product Manager // Developer Tools // +336-87-11-27-55 

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

OLEKSANDR GARAGATYI

SENIOR SOFTWARE ENGINEER

Red Hat 

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--
Oleksandr Garagatyi
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

OLEKSANDR GARAGATYI

SENIOR SOFTWARE ENGINEER

Red Hat 

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

OLEKSANDR GARAGATYI

SENIOR SOFTWARE ENGINEER

Red Hat 

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    



--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

Back to the top