# Less batteries? **URL:** \ **Category:** Ansible Developer\ **Tags:** galaxy-ng\ **Created:** [March 23, 2015, 10:09pm UTC](https://forum.ansible.com/t/less-batteries/17821 "2015-03-23T22:09:04Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Marc\_Abramowitz](https://avatars.discourse-cdn.com/v4/letter/m/a5b964/32.png) [@Marc\_Abramowitz](https://forum.ansible.com/u/Marc_Abramowitz)\ **Post date:** [March 23, 2015, 10:09pm UTC](https://forum.ansible.com/t/less-batteries/17821/1 "2015-03-23T22:09:04Z")
Apologies if this has come up before and/or beaten to death. I wonder if it makes sense to prune a lot of modules in core and extras; take them out of those repos and let them be their own projects – which get installed by Galaxy (or even by pip, as I think that would take advantage of many man-years of work on pip, PyPI, etc.)? Advantages: - There will be a lot less PRs for the core team to go through =\> less work =\> less stress - Core team members can spend more time on solidifying the core and less time having to know about a bunch of specialized modules. Let the subject matter experts concentrate on the modules that they know and care about and can easily test. - PRs to core can get merged sooner – there is a substantial backlog at the moment. - Modules can be developed quicker, without being couple to an ansible release. Many of the modules could probably have a faster development cycle, but are held back by the fact they are released with ansible. I think the “batteries included” approach (as people often speak of in referring to Python) is a great one, but there are some conditions under which things work better and others where it doesn’t work as well. I think “batteries included” works well when you have a reasonable number of batteries that are well-understood and stable and not likely to change much and are used by a large proportion of the population. There are probably a bunch of ansible modules that fit this criteria but probably also a lot that don’t fit these criteria, because they have evolving feature sets, are developing quickly, are very specialized and used by a small number of users, are difficult to test without having expensive hardware, etc. If you look at Python, you’ll find that they are very discerning about what they will accept into the core. And they are clear that not accepting things into core is not only a benefit to them (less stuff to maintain), but it’s often better for the code in question (it can evolve much faster when not coupled to a Python release). Thoughts? ---
**Author:** ![Greg\_DeKoenigsberg1](https://avatars.discourse-cdn.com/v4/letter/g/838e76/32.png) [@Greg\_DeKoenigsberg1](https://forum.ansible.com/u/Greg_DeKoenigsberg1)\ **Post date:** [March 24, 2015, 1:32pm UTC](https://forum.ansible.com/t/less-batteries/17821/2 "2015-03-24T13:32:06Z")
Not speaking for the core team, but here's my $0.02: I think most people agree in principle with what you're saying. The question is, how is it best achieved? This was precisely the rationale for the Core/Extras split -- which has yet to pay full dividends. The need for Core is clear. Perhaps it could be smaller. The need for Extras is also clear: there needs to be a space for promotion/relegation of modules. The focus, for now, is Ansible 2.0. Once that's out the door, the focus will move to making the most of the Core/Extras split, with a more solid platform to work from. That will be the time to have such a discussion in earnest, I suspect. --g ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [March 24, 2015, 3:50pm UTC](https://forum.ansible.com/t/less-batteries/17821/3 "2015-03-24T15:50:01Z")
Marc, Ansible already makes it easy for you to use 'non official' modules and other plugins, it was designed for this since the start. Just drop it in a appropriately named directory adjacent to your play, in your role or set in your ansible.cfg. So why do so many people submit the plugins instead of using and sharing them directly? One of the reasons is that they prefer 'official' modules as they already trust the ansible project and that extends to the plugins included. Those included in the project tend to have a normalized interface, this is something we strive for to keep the user experience from diverging too much (we can use your validate\_certs vs verify parameter as an example). Another reason is that the core team looks at function reuse and sharing and we push the PRs in that direction. Please note that we are currently closing issues much faster than they open, but we still have a large backlog to deal with from when this was not the case. I agree not everything needs to be in ansible and that there are still improvements to make, we have opened other threads in ansible-devel to discuss this with the community and have been trying to improve the process as we go. One of those is to make both galaxy and extras a better place to share, discussions over which are still ongoing. We have also instituted a freeze on features during releases, as another complaint was about release instability, this is why we currently are on 1.9-RC2. This of course impacts the merge rate of PRs that add features, we try, but we have not been able to have it both ways 😉 .