[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [che-dev] Simplify mounting of project sources to plugins
|
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
