Maybe the best thing to do for now it to revert it and send a PR to the RFC repo for a proper discussion?
On Fri, Jan 13, 2017 at 2:26 PM, Daniel Lobato Garcia <[email protected]> wrote: > On 01/12, Marek Hulán wrote: > > > > > > > I strongly disagree that this does not have big benefits. Using > internal > > > > Foreman objects in templates is a bad practice. It blocks us from > > > > improving > > > > our code. Therefore it's very important to build a DSL that users > can use > > > > in templates and keep that compatible. We can then later change the > > > > implementation of host_param_true method without any templates > changing. > > > > Think > > > > of this as a templating API. > > > > > > > > Another less significant benefit is that for plugins it's easier to > > > > wrap/alias > > > > the template method rather than manipulating something that's used > > > > internally in @host. Still not ideal but that should be solved by > > > > https://github.com/ theforeman/foreman/pull/3701 > > > > > > > > Of course it will require users to migrate to new template helpers > which > > > > is > > > > why we move there slowly and hopefully with proper deprecations. I > was > > > > hoping to do the update for community-templates since it's very easy > > > > migration. > > > > > > > > If you think it's too complicated for users we could provide rake > task or > > > > migration. But please don't revert this. > > > > > > Yes, if you provided a migration it would be much better. That doesn't > > > really solve the problem with people using the foreman_templates plugin > > > who will have those changes reverted, but I guess it's better than > nothing. > > > > > > There's still dozens of other things allowed for @host in the Jail that > > > aren't covered by these macros. What's the plan for those? > > > > Whenever we have a chance, we should move from internal objects to > macros. The > > more macros we have the higher the chance is that we can keep templates > > compatible. > > Sorry but I oppose this. Some internal objects are quite stable, in > fact people rely upon them successfully - but we break the compatibility > for apparent advantages that IMO are not worth the hassle. > > @host.operatingsystem, @host.architecture, etc... and @host.params, are > very stable objects that can safely be called from templates and expect > that will work for a long time. Not only our users do it. We also relied > upon these internal objects for years. > > The first community templates PRs which are 4 years old used > @host.params, @host.operatingsystem, etc.. Those are stable enough to > not warrant writing a macro for them > > What we did on #16740 is basically renaming things around and deprecating > params for macros that don't do anything but calling @host.params > themselves. > > I would argue for the opposite way of thinking. When we change how > these internal APIs work, we should deprecate them. If these APIs > remain stable, don't change anything as it provides no value, and brings > headaches and wastes time. Time wasted on writing this thread, on the > people who write and review PRs in the project and associated ones > (templates, the migration to new macros, fixing anything that might break, > and adding more LOC which complicate our codebase). > > > > > > I still think this provides more headaches than any benefits. > > > > I hope that following helps > > * https://github.com/theforeman/community-templates/pull/343 > > * https://github.com/theforeman/foreman/pull/4187 > > * https://gist.github.com/ares/5435226ef0317613535101765404d3f5 > > > > -- > > Marek > > > > > > > > > > > - Stephen > > > > > > > -- > > > > Marek > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups > > > > "foreman-dev" group. > > > > To unsubscribe from this group and stop receiving emails from it, > send an > > > > email to [email protected]. > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > Daniel Lobato Garcia > > @dLobatog > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
