python package in salt/modules dir

[shadowfac-chc]

Hi all,

I am looking to add some additional Gentoo specific modules. I wanted to add support for Gentoo's eselect tool. Eselect is a "multi-purpose configuration and management tool". It allows for easily setting things such as the active python version or java-vm.  Eselect itself has several modules to it that may or may not be installed. For example, if a system has no java implementations installed, it will not have the java-vm eselect module. Due to the modular nature of eselect, it would make sense to have an eselect package under salt/modules with the various eselect modules under salt/modules/eselect/. Is this possible? Or is there a better way to achieve this?

Thanks.

[Joseph Hall]

This reminds me of the alternatives system that ships with Red
Hat-based distros. I seem to recall seeing it installed in Ubuntu, but
a little Googling finds me dpkg-reconfigure for Debian-based distros
such as Ubuntu.

It feels more salty to me to have a single module name which performs
the appropriate functionality depending on which distro it's run on
(such as pkg running yum, apt, pacman, etc, depending on what it finds
available). But from the looks of it, the usages between alternatives
and dpkg-reconfigure are probably very different.

That said, while I can't speak any further for dpkg-reconfigure, it
looks like alternatives does have a somewhat modular nature about it.
I installed sendmail, and then exim, on a CentOS 6 box just now, and
each individually populated parts of /var/lib/alternatives/mta.
Presumably, if I removed sendmail, exim and postfix, that file would
disappear entirely.

Is eselect similar in nature to this?

> --
>
>



--
"In order to create, you have to have the willingness, the desire to
be challenged, to be learning." -- Ferran Adria (speaking at Harvard,
2011)

[shadowfac-chc]

Going off of your description, I would say it is similar to the alternatives system as there seems to be an overlay in functionality. Therefore I would agree that it would be more salty to have a virtual module that can be implemented depending on distro, much like the pkg module. (Perhaps a discussion can be had on implementing this virtual module?). It does seem that although they both preform similar actions, eselect and alternatives go about it in different ways (from what I understand from reading the alternatives salt module).

Still at least of the Gentoo eselect component, it makes sense to be to have a package with modules that provides the full eselect functionality. This would allow salt to detect which eselect modules are available for various minions. For example, if minion1 has java installed, but minion2 does not, only minion1 would have the eselect.java_vm salt module available.

[Thomas S Hatch]

So a package does work, but not in the classic way. You can and a directory with a __init__.py which can then load the rest of the modules in that directory. I have not played around with it much though, this was contributed around 0.10.2

--
 
 

[Erik Johnson]

--
 
 

Slightly off-topic, but could you look at adding a list_upgrades() function to ebuild.py? It should return a dict with the pkg names as keys and the version to be installed as the value. This function already exists in several of the other linux pkg providers.

Thanks,

--

-Erik

"For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring."  -- Carl Sagan

[shadowfac-chc]

I'll look at adding list_upgrades to ebuild.

Any thoughts or a generic package that eselect and alternatives could both implement?

-- Timothy Messier