Reduce dependency on other modules

[tux-o-matic]

It feels like setting up this module its over complicated and so is maintaining its code due to its dependency on some other modules.

• EPEL: Only needed by EL 6 and a simple Yumrepo resource can take care of that, no need for a module.
• stankevich/python: The module cannot keep up with all the changes done to pip and Python 3 so lets call use pip directly in this module. (Remember that Puppet's Package resource can use pip as a provider)
• vcsrepo: It should be optional and the latest puppetboard release should be installed from pip by default.

[rnelson0]

Epel is 'just ' one repo, but it could be any of a number of versions of the repo (osmajorversion, devel, scl, etc). It would be bad both to replicate that feature set here, or to conflict with usage of that module independent of puppetboard. What makes this overly complicated to set up? PMT manages dependencies including transitive ones for you automatically, and plenty of tools exist to update you Puppetfile and fixtures the same way. -- Rob Nelson

[juniorsysadmin]

YesNo. Soft dependencies should be removed from metadata.json

Puppet's native handling of Python via the native pip provider is limited, with a bunch of bugs in Puppet 3.x

[tux-o-matic]

@rnelson0 Only main EPEL is needed and that's just for EL 6, and you don't even need to hard code it thanks to Facter.
In Hiera (JSON), it just looks like this

"epel": {
 "baseurl": "https://dl.fedoraproject.org/pub/epel/%{::operatingsystemmajrelease}/%{::architecture}/",
 "descr": "Extra Packages for Enterprise Linux %{::operatingsystemmajrelease} - %{::architecture}",
 "gpgcheck": true,
 "gpgkey": "https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-%{::operatingsystemmajrelease}"
}

In the current block setting the python class, add some check for EL 6 and if the Yumrepo['epel'] is not defined. And there you go, this module is free from one dependency (EPEL) and one step closer for getting rid of the Python module.

@mterzo, do you agree about switching to latest pip release by default or even remove the GIT install all together now that you took over as maintainer of Puppetboard?

[mterzo]

I'm not a fan of the git installation, mainly due to lack of testing right now with all the variations being introduced by dependency management on pypi packages. Installing via the package atleast puts us in a better place with known good. Some users still may want bleeding edge, though using git+https as the package might be easier there.

I dropped the epel module on all my personal stuff long ago using your proposed method. I'm behind that 100%.

Using pip directly seems like a bad idea. First off is it pip or pip3. Now we start installing packages into the site-packages mixing system packages and pypi packages. This will become a nightmare for those that have other python apps on the host. Using the python puppet module is clunky currently, the module just needs some extra help.

All that said, I run my puppetboard in a container which solves these problems. There was a refactor of this module proposed in an open issue over a year ago, I couldn't tell if it occurred. I was thinking about another refactor myself trying to add a docker option.

[tux-o-matic]

Thanks for the feedback @mterzo.
Since PuppetBoard at this stage is only targetting Python 2.6 and 27, pip3 should not be seen as an issue. Puppet is ready for the "future" since there is a pip3 package provider.
Both pip and pip3 package providers in Puppet support 'install_options' which should give the possibility to install in a custom folder instead of site-package.

So how about starting by removing the EPEL dependency? I can come with a PR for that.

[mterzo]

2.6 will be evtually be dropped. So far there is only 1 issue that I know of with python3 and we have a fix. Again more testing we have the better off we are gonna be on that front.

I was thinking maybe custom install option which would essentially be creating our own virtual environment. I not sure if installing puppetboard with the install option of its location would be passed to all the dependencies. If not then we have to install them all individually.

Putting up the pr on the epel is a good start.

[tux-o-matic]

Would be nice to keep some level of compatibility with Python 2.6 for all the EL 6 users out there.
When using pip directly, forcing a target directory will also be fore the dependencies. So I can only assume (till I test) that using 'install_options' with the pip package provider would have the same effect.

[tux-o-matic]

The Python module section supposed to install Virtualenv is a bit odd.
It seems "virtualenv" ( package name only used by pip, not rpm) is declared as a package then collected and redeclared with pip as the provider to install the package.
If that's the case, EPEL isn't needed anywhere.

[mterzo]

Well keep 2.6, at some point I expect a library needing at least 2.7.

[rnelson0]

I guess I don't understand what the issue is with having epel as a dependency. If you think it's optional, though, please remove the dependency but do not add a file resource for the repo so that it won't conflict with users of epel.

[tux-o-matic]

@rnelson0, EPEL isn't needed at all for this module but there is a conflict between the Puppetboard module and the Python module around virtualenv.
The Python module installs it via pip where it's just named "virtualenv" but the Puppetboard module as a check for it with the package name as distributed by the Linux package provider. This "not defined" check is just checking that the EPEL distributed version isn't installed to install it from PIP, doesn't make much sense.

So I'd like to remove EPEL and to do it properly this conflict should be fixed.

[tux-o-matic]

I gave up pretty fast on this module because of all the dependency. Be it for OS support or not, it seems to be too much code and dependencies.

All my Puppet masters were installing and setting the various resources for Puppetboard via some Package/File/INI_setting resources, I ended up creating a module.
So if someone is curious to see how can Puppetboard be installed without a collection of complicated modules (no need for EPEL either).

[igalic]

thank you very much, @tux-o-matic for taking the time to comment here again.
having your module documented here, hopefully means more people can benefit from it.

i take it we can close this issue then?

[tux-o-matic]

@igalic for me there is an alternative. I'll leave it to the community to choose what to do about it. You can close the issue.