> Cons: In a long(er) term, YouTube might start to change its API's and that will require frequent(er?) update to mps-youtube formula definition.
This ("frequent") doesn't make much sense. YouTube might change their API some day, which would require a youtube-dl update, and an update to the vendored resource in mps-youtube, if mps-youtube doesn't bump itself. But I don't see YouTube changing their API from day to day, or month to month.
> The youtube-dl README gives examples of using it as a Python library so I guess it does have an API.
Yeah, never noticed that (very short) section, sorry.
> Because it doesn't install it in a form we can reuse in other formulae.
I don't think the Python interface of youtube-dl is supposed to be reused in the first place. There's no public API documentation. The fact that it is on PyPI is probably due to demand (just my guess, take it with a grain of salt); I learnt from first hand experience that whenever you build an open source Python application, people will ask for it to be on PyPI, whether it's suitable or not.
Also, is there any other formula that needs to reuse it?
As a youtube-dl user: no, it does NOT break regularly. youtube-dl supports ~700 sites; just look at the [extractor](https://github.com/rg3/youtube-dl/tree/master/youtube_dl/extractor) directory. YouTube functionality alone is very stable, it doesn't change very much. Look at the [history of `youtube.py`](https://github.com/rg3/youtube-dl/commits/master/youtube_dl/extractor/youtube.py), only a couple of commits in the past few months, mostly non-consequential. This mps-youtube only deals with youtube as far as I can tell, so youtube-dl doesn't need to be updated often.
If youtube-dl upstream chooses to zipapp their stuff I don't see why we should do our own thing.
I was surprised to see @nijikon push a640294 to #8361 too (not complaining; he was correcting my mistake), but since I have pandoc (and the Haskell stack) anyway I didn't think too much about it.
Now that I looked into it, there was something wrong with their 2016.12.31 release. `youtube-dl.1` depends on `README.md`, and `README.md` depends on `youtube_dl/*.py youtube_dl/*/*.py`, etc. Now all those *.py files are newer than `README.md`, so make decides to regen `README.md` and `youtube-dl.1`. I hope they're not doing the packaging by hand, but maybe they are... 😱
Since this only applies to 2016.12.31, I opened #8424 to fix this.
In our defense, there weren't much we could do. The tarball was screwed up, so we basically had three options at that point:
1. Drop the man page / make it optional — more destructive than adding a somewhat hefty build dependency;
2. Do some shady touching after unpacking (didn't check if the man page was actually up-to-date);
3. What we did.
3 was the best for the great majority of users and maintainability combined. Thanks @blogabe for bringing this up, now we should be back on track.
For the record, pandoc was in there for HEAD since https://github.com/Homebrew/legacy-homebrew/pull/29360.
youtube-dl: make pandoc a head-only build dep again
===================================================
- [x] Have you followed the [guidelines for contributing](https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md)?
- [x] Have you checked that there aren't other open [pull requests](https://github.com/Homebrew/homebrew-core/pulls) for the same formula update/change?
- [x] Have you built your formula locally with `brew install --build-from-source <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Does your build pass `brew audit --strict <formula>` (after doing `brew install <formula>`)?
-----
Fixes #8420.
@waldyrious
> I didn't mean to spam people
I'm sure you were well meaning, didn't assume malice. Just a suggestion: you could have waited for project maintainers to take a look, at their leisure, who in this case could have solved it right away; in the case that they couldn't, that's probably the time to escalate to a wider group of people.
By the way, I appreciate the credit, but could you please remove my handle from the commit message? Otherwise, I'll get an email whenever someone pushes a rebased/cherry-picked version of this commit to their own fork...
Just submit a PR with this patch
```diff
diff --git a/Formula/tldr.rb b/Formula/tldr.rb
index 1601222..d5e1c44 100644
--- a/Formula/tldr.rb
+++ b/Formula/tldr.rb
@@ -15,6 +15,7 @@ class Tldr < Formula
depends_on "pkg-config" => :build
depends_on "libzip"
+ depends_on "curl" unless OS.mac?
def install
system "make", "PREFIX=#{prefix}", "install"
```
Shouldn't have been hard to figure out if you just
```
grep -r curl
```
or better yet,
```
grep -r 'depends_on "curl"'
```
in this repo. I understand it might be very important for you, but I don't think mentioning a bunch of people from another project is very polite.