New formula: Ansible #21602
New formula: Ansible #21602
Conversation
Configuration management and IT orchestration tool.
|
Ansible project lead here :) Hi, glad to see a pull request to add this to homebrew! Looks good. A few comments: Think you MAY want the release tarball instead - Also can this maybe set up a proper ansible.cfg to pick the install path so
Might avoid user Q&A about where to find the module paths. Thanks! On Thu, Aug 1, 2013 at 9:22 PM, Ches Martin notifications@github.comwrote:
|
|
This was rejected in Homebrew previously. See the discussions in #20554 and #21585. As we have the project lead here: for this to be in Homebrew it needs to be installable in a form similar to something like |
|
@mpdehaan Ah, I didn't find an official release tarball linked on the site, thanks, I'll update this. About the module path though, it works out of the box since it gsubs everything, including If you think there's otherwise anything that should be mentioned in a post-install message though, you're the man to say it 😄 |
|
@MikeMcQuaid Sorry about the dupe, I think I was searching with closed issues filtered 😩 |
|
@ches, ok good to know. Vendoring is kind of unacceptable to me, especially for a general perspective on security and package management. In general, the Python community is a lot less open to vendoring than Ruby land, but there's also a lot more focus on API compatibility and interfaces change a lot less. It seems if you had recipes for paramiko and PyYAML and Jinja2 that had similar, you would have it solved? It seems to be an of an issue of "don't cross the package manager streams and I need to pin versions", which seems to be a reasonable goal. I'm not really sure how else you would handle dependencies from an upstream source, but vendoring seems to be a no-go. |
|
If there's vendoring within the formula that's potentially fine for this use-case (but other maintainers would need to agree). I do get that you have other dependencies you'd rather not vendor but unfortunately the harder these things are to package/distribute the less likely they are to be treated as "applications" that exist outside of a particular language ecosystem. Incidentally when I was referring to vendoring previously that doesn't necessarily have to mean "put these libraries in your source tree" but could mean "optionally install these libraries at ansible installation time". |
|
As an aside, FWIW it's well-known to me that a package available from PyPI, Rubygems, etc. won't be accepted (though I thought exceptions might be up for discussion if, like this one, they aren't Homebrew-compatible), but it was not clear to me that one requiring pip dependencies would be rejected -- the docs illustrate DSL support for declaring Python module dependencies! IMO some clarification should be noted on that wiki page about the dependency policy. If it's there, I missed it. |
We're not importing "all of PyPy" here. That's an overgeneralization, of course, but we're not going to start pulling in Python packages en masse. |
|
For the time being, I've set up an ansible tap based on @ches's formula -- which seems to work perfectly. Thanks! If/when ansible gets into Homebrew proper, I'd be perfectly happy to take down my tap and redirect users to the official Homebrew-packaged version of ansible. This is just meant to be a stop-gap solution. |
To expand on Adam's answer a bit more... We do package some standalone CLI tools written in Python even if they're also on PyPi, but the deeper into PyPi dependencies things get, the less likely we are to package them. We don't repackage general Python libraries unless there's a really compelling reason to make an exception. Our thinking is: PyPi already handles Python dependencies, etc. We don't want to duplicate that work. If there are multiple Python dependencies for a given package, which the user will need pip to install, then that's a sign that there's less value in Homebrew packaging it unless there are very specific reasons why that would be better. In this case, the easiest route to packaging Ansible would be if a standalone tarball was available that packaged all of the required dependencies with it. The authors of, for example, gist (Ruby) and ack (Perl) do this to make packaging easier without requiring interacting with those languages' package managers, and to help their goals of making the software usable as a standalone CLI tool independent of that language's package management ecosystem. If there isn't interest in doing that, then maybe Ansible isn't a good fit for Homebrew (or vice versa). @singingwolfboy Thanks for setting that up! |
|
"In this case, the easiest route to packaging Ansible would be if a We believe vendoring is a very bad practice for software keeping up to date On Wed, Aug 7, 2013 at 3:16 PM, Misty De Meo notifications@github.comwrote:
|
|
@mpdehaan As mentioned previously, you only have to vendor within the OSX formula. Also, vendoring tends to be the OSX way of doing things; it is how all .app bundles are managed, it's how Railsland does things and it's how the other utilities that get included in Homebrew do things. Sadly it sounds like we're at a blocking point here where this isn't going to get resolved so closing (but will feel free to reopen or review a approach that doesn't rely on the user using |
Configuration management and IT orchestration tool.
This is a Python package that is published to PyPI, but its installation is broken with Homebrew
pipbecause of hardcoded paths. In discussions about fixing standard Python installation mechanisms, the maintainer has stated pretty resolutely that he wants it to be considered an application and not a Python library/package. It is also in MacPorts.I first did this with a less brute-force approach that requires a two-line patch, but it leaves the user to add a config file to change an essential default path, and it leaves incorrect paths indicated in man pages, etc. So I've ended up doing exactly what MacPorts does.
/cc @mpdehaan