I’ve raised issue #8324 for this, but it got summarily closed. Is that really how the ansible project deals with issues it doesn’t understand now? If I were a new contributor I’d be very disheartened that a fully fleshed out bug report was closed in this way, as a longstanding contributor I’m just exasperated instead.
If you run ansible-pull to pull from a remote repository to a directory that does not exist, ansible-pull fails.
This can be fixed by reverting #7667. I’ve commented on #7667 to request further clarification - in my view the pull request should never have been accepted because it doesn’t really explain what problems it solves (other than a reference to python interpreter).
ansible-pull has been working for me in this way for nearly a year until this change was introduced. Moving forward I’d like to make ansible-pull work again, perhaps by incorporating the intent of #7667 in a way that doesn’t break ansible-pull.
I think you know me better than that to assume malice. Maybe we did misread a bug report. That’s possible.
My comment on the ticket was that it seems useful to apply a -i to ansible pull and be able to supply an inventory file, which is what the patch you were complaining about was.
Naturally if you have a problem, asking for more clarification is GREAT but coming at it this way doesn’t do the list, me, or you, any good.
The code in question in the pull request DID make sense to us completely.
Suppose you have a non-standard python interpreter, like so:
In this case, ansible pull using that python was not possible before.
To fix this problem, you just have to add a “-i ” to the ansible pull location.
Now, it’s probably very likely you have a use case for ansible-pull that you feel is broken, that we should try to accomodate, but it doesn’t mean we have to revert that other commit.
I’m assuming what you are requesting is “-i” should be optional, but I don’t think we need to break one person’s fix to be able to get things to work the way you want them to as well.
We’ll definitely look into whether we thinks this works or not but would appreciate not assuming we are jackasses.
I think I was more upset by the summarily closed bug report more than anything else. Had you asked for clarification on the bug report I would happily have given it (and indeed the clarification is getting sorted in the original pull request now). Perhaps we can both agree that we could have both gone about this in ways that are better for both of us and the list
I agree that it’s useful to pass -i and supply an inventory file - my problem is that that is now broken if the inventory file is in the repo being pulled down - i.e. the inventory file does not exist at the time that ansible-pull is run, but does by the time ansible-pull runs ansible-playbook.
ansible-pull already uses the -i argument when calling the ansible-playbook bit - it’s unclear whether it’s used for the bit that in effect does
ansible -m git/hg -a repo=http://git.whatever/
Anyway, this is also covered in #7667 - the hope is we can move the reading of the inventory file to after the call to ansible - but it might be needed for that call, in which case something that handles it better is required.
Certainly I don’t think any of you are jackasses! I would just like my bug reports treated as not coming from a jackass either! My reason for raising a bug report rather than a pull request reverting that commit was that I assumed you had good reason for it, I just didn’t understand what it was - hence the bit in my original bug report saying that I was trying to understand the intent so that I could try and solve both problems.
We have a very large number of pull requests and it is difficult how GitHub makes the default behavior of code change “throw code over the wall” versus “talk about it first”. itHub is also not the best medium for communication, because on a ticket it will just be two people, versus everyone, and not everyone can weigh in easily (compared to the mailing list). With 800 people trying to contribute code all at once, trying to be somewhat efficient and not overly wordy can be misinterpreted.
What about the following logic to serve both use cases?
-i is specified:
pass the -i along to the git checkout command only if the file exists
otherwise pass “localhost,” to the git checkout command
always pass -i to the playbook as given if specified
otherwise pass “localhost,”
Would you like to work on making both of these work at the same time?
Today I hit the same problem, basically ansible-pull complain about inventory file which is in the remote repo and not loaded yet. Search around brings me here but not sure about solution yet.
However, I suspect it’s not in the last ‘release’ - so if you’re not on bleeding edge, you’ll have to wait until 1.8 is released (this month, we’re told) before your ansible-pull will include the fix.
