[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [che-dev] Simplify mounting of project sources to plugins
|
I think that having just one project path for all the containers is ok. Not sure user needs to define their custom path for a certain container.
And go path can actually be in /projects. We just need to ensure that if a user uses golang projects we set Theia project tree path to go path. Then user can open project in the tree.
We need:
- check UX on gitpod as they already covered this usecase
- @Lukas do not allow changing project mount path
- set gopath to /projects and ensure that go projects get cloned to /projects/src/githosting/projectName
Thanks,
Gorkem
On 22 Jan 2019, at 12:14, Mario wrote:
> Let's make an example. The user defines a workspace with 3 containers
> (3
> tools in a devfile):
>
> - Theia: it has mountSources=yes and the projects volume bound to
> folder
> /projects by default (i.e. defined in che-plugin.yaml, users don't
> need to
> specify anything in devfile)
> - Go LS and tooling: the same as Theia, the user doesn't need to
> specify
> anything about volumes or mount sources because the default should
> work for
> him
> - His own runtime tool: it is where he will be able to open a shell
> and
> build / run his application. He is used to keep his sources /go/ so he
> will
> want to set `sourcePath=/go/` in the devfile
>
I guess this is valid but then why can’t we resolve this by changing
the one mount path for the workspace
instead of plugins individually from /project to /go. How common is such
containers that we will have more than
one on the same workspace? Also how many developers exist that have an
existing containerized tool that they
want to drop into a Che and use immediately without making the change on
their container from /go to /project.
This feels like we are looking for use cases for a technically viable
feature.
> In that scenario Go LS and Theia will use the same path (/projects
> bound to
> the volume /projects folder), the user will be able to use his own
> container and specify the source code path as required by his
> environment
> (/go bound to the volume /projects folder) without creating symlinks
> or
> changing environment variables. Wouldn't it be a valid and important
> scenario to support?
>
> On Tue, Jan 22, 2019 at 5:34 PM Gorkem Ercan <gorkem.ercan@xxxxxxxxx>
> wrote:
>
>>
>> I am a bit late to the thread but why is the source code path a
>> plugin
>> level concern?
>> I can see this being a workspace (IDE) level setting but at the
>> plugin
>> level changing the
>> path for each plugin does not sound like something that will work.
>> Most of
>> the plugins
>> and tools that Che uses comes from desktop. These tools are used to
>> working with
>> single filesystem hierarchies and with concepts like workspaces, I do
>> not
>> think they
>> will be ready to handle own file system hierarchy and a way to map
>> this to
>> IDE’s hierarchy.
>> Unless we are assuming that plugins will work on their own and never
>> communicate with each other
>> or the IDE this setting is an invitation to break things.
>>
>> Thanks,
>> Gorkem
>>
>> On 22 Jan 2019, at 11:19, Oleksandr Garagatyi wrote:
>>
>> Yes, Lukas, you are completely right. We can’t clone
>> Che-plugin-broker
>> into /projects since traditional go tooling would not work
>>
>> вт, 22 янв. 2019 г. в 18:01, Lukas Krejci
>> <lkrejci@xxxxxxxxxx>:
>>
>>>
>>>
>>> On 22. 01. 19 16:43, tmader@xxxxxxxxxx wrote:
>>>> On Tue, 2019-01-22 at 17:32 +0200, Oleksandr Garagatyi wrote:
>>>>> @Thomas Maeder
>>>>> In Go world projects are located by the GOPATH. Usually, GOPATH
>>>>> env
>>>>> var is exported in bash profile or so. E.g. export
>>>>> GOPATH=/home/user/goAfter that Go compiler and utils follow next
>>>>> structural location of files:
>>>>> $GOPATH/src <- projects AND dependencies (though dependencies not
>>>>> always go here)
>>>>> $GOPATH/bin <- compiled and packaged Go apps (usually added to
>>>>> PATH
>>>>> to launch tools from it, often used for go based linters and other
>>>>> Go
>>>>> related tools)
>>>>> $GOPATH/src contains folders that represent Go packages and
>>>>> usually
>>>>> include source hosting like github.com or golang.org.
>>>>> For example, when I'm working on Che broker repo my path is
>>>>> $GOPATH/src/github.com/eclipse/che-plugin-broker or
>>>>> /home/gaal/workspace/go/src/github.com/eclipse/che-plugin-broker
>>>>> on
>>>>> my system in particular.
>>>>> All the Go tools like linters, compiler, and others expect GOPATH
>>>>> to
>>>>> be populated in the system and structure to be respected.
>>>>>
>>>>> Hope it helps. If not, please, let me know.
>>>> Thanks for the explanation. Howerver, I don't think it's a problem
>>>> for
>>>> the tooling, because the tooling will be installed in the plugin
>>>> sidecar, where we control the value of $GOPATH (as well as in the
>>>> Theia
>>>> container). Why should GOPATH not be /projects?
>>>>
>>>
>>> You need to checkout your code into a particular subdirectory of
>>> GOPATH
>>> that corresponds to the "structure convention" of Go, if I am not
>>> mistaken (and please correct me if I'm wrong, Alex, I'm a Go noob).
>>>
>>> E.g. because che-plugin-broker is hosted on github, it *needs* to be
>>> checked out precisely to
>>>
>>> $GOPATH/src/github.com/eclipse/che-plugin-broker
>>>
>>> is that compatible we how we checkout stuff into /projects?
>>>
>>>> /Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
