Hi all,
I expressed the same perplexities yesterday in my discussion with Hans,
in a short and more succint form, but same perplexities. Peter's email
summarize very well my same points of confusion. Current implementation
of projects and envronments is also difficult to be explained to our
users and developers and they are experiencing our same concerns on this
topic.
I personally do not understand why and when we could have a use-case for
an envronment not associated to a project. What's the case for this, can
we make an example? I wasn't not able to find something that convinced
me from the very early days Istarted working with Hop.
Same pain as Peter with assignin environments' names to different
projects. Moreover, really confused on having all the environments
present in the environent's combo when a specific project is selected.
For this reason, some time ago I wrote an email to this list I sent an
email by proposing to hide, by using an option parameter, environments
that are not related to the current project.
For this reasons I also find more understandable and logical the idea of
having a project that is bound to one or more environments with
environent's namespace that is per project (so that we can have two
environments with same name for different projects).
Cheers
Sergio
Il 02/11/2021 13:09, Peter Fabricius ha scritto:
Hi,
For me, this is also one of the more confusing parts of Hop right now.
An environment in the current Hop version always has exactly one project
reference in its definition. On the other hand, the names of the environments
must be unique in the context of the Hop installation/configuration. So from
this perspective they have a reference to the local system and not to a
project. Confusing !
I find especially the uniqueness of the environment names in the hop
installation/configuration problematic. As long as I only work with my own
system everything is ok, but if projects AND environments are shared between
systems it gets confusing. To avoid duplicate use of environment names on a
target system they should not be Hop installation/configuration specific but
need to have a smaller namespace.
For these scenarios environments that are bound to one project are much clearer.
With the use of parent projects and inherited environments it should still be
possible to have environments that span muiltiple projects, so we are not
loosing flexibility.
Cheers
Peter
-----Ursprüngliche Nachricht-----
Von: Hans Van Akelyen <[email protected]>
Gesendet: Dienstag 2 November 2021 09:22
An: [email protected]
Betreff: Environments linked to projects or not
Hi Hop enthusiasts, developers and philosophers
I have had an interesting discussion with Sergio on Jira ticket HOP-3471
[1] but we would like to get a bit of a broader consensus.
So the main question is: do we see an environment as something linked to a
single project or are they objects that can be reused for several projects?
Both approaches have pro's and con's but we need to agree on this as it
would change user experience and maybe how they are stored.
Currently an environment is a semi-standalone object, it is not linked to a
project in the hop-project.json but it is linked to a project in the
hop-config.json. In the GUI all environments are shown, not only the
environments linked to a project. When using hop-run I *think* you can
point to an environment that is not linked to the project in the
hop-config.json.
My personal preference would be to unlink them completely and have
environments that could be used by multiple projects. This gives greater
flexibility when you would want to divide your projects on a lower level.
con would be that you would always see all available environments defined
in your hop-config.json.
I would love for some opinions on the matter so it can be set in stone once
and for all. And we can update our docs to reflect this decision [2][3].
Cheers,
Hans
[1] https://issues.apache.org/jira/browse/HOP-3471
[2]
https://hop.apache.org/manual/latest/projects/projects-environments.html#top
[3] https://hop.apache.org/manual/latest/projects/index.html#_environments
