@MikeMcQuaid Just blow away the whole caveats section? I agree because readers are supposed to read https://github.com/rg3/youtube-dl#do-i-need-any-other-programs.
@humitos
> Let me explain it a bit what is happening for me:
You're absolutely right. I didn't read the two `conf.py`s carefully when I submitted this issue.
> As workaround by now, are you specifying the Python configuration file from the Advanced settings? Can you try that and let me know?
Thanks, I added `docs/source/conf.py` as "Python configuration file" and at least the last build succeeded: https://readthedocs.org/projects/storyboard/builds/5169712/. It's kind of weird RTD can't find `docs/source/conf.py` though; it's one of the few standard Sphinx configurations.
Why? As I said, all GitHub releases are published to PyPI. https://pypi.org/project/youtube_dl/#history
Plus the fact that we're using GitHub release tarballs, not PyPI source tarballs.
youtube-dl: skip make step for stable and stop bottling
=======================================================
- [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>`)?
---
- Make artifacts are already included in release tarballs (at least for now);
- Stop bottling (#11281);
- Remove useless comments (all GitHub releases are published on PyPI).
Nothing. `rtmpdump` is just an external executable optionally called by `youtube-dl`, like `ffmpeg` or `avconv`.
```
brew install youtube-dl --with-rtmpdump
```
is equivalent to
```
brew install youtube-dl rtmpdump
```
Frankly I'm surprised there's such an option.
Zipping up source files into an executable bundle, etc. The make step has already been run when making the release tarball though, so running it again only checks the timestamps (and for whatever reason makes CONTRIBUTING.md and docs/supportedsites.md which we disgard).
Basically, we can bypass the make step and it still works for stable releases.
```diff
diff --git a/Formula/youtube-dl.rb b/Formula/youtube-dl.rb
index 7a3fb28d54..058447c605 100644
--- a/Formula/youtube-dl.rb
+++ b/Formula/youtube-dl.rb
@@ -22,7 +22,7 @@ class YoutubeDl < Formula
depends_on "rtmpdump" => :optional
def install
- system "make", "PREFIX=#{prefix}"
+ system "make", "PREFIX=#{prefix}" if build.head?
bin.install "youtube-dl"
man1.install "youtube-dl.1"
bash_completion.install "youtube-dl.bash-completion"
```
> Well it does require make but it doesn’t compile anything per se
Depending on your definition of compilation.
```make
youtube-dl: youtube_dl/*.py youtube_dl/*/*.py
zip --quiet youtube-dl youtube_dl/*.py youtube_dl/*/*.py
zip --quiet --junk-paths youtube-dl youtube_dl/__main__.py
echo '#!$(PYTHON)' > youtube-dl
cat youtube-dl.zip >> youtube-dl
rm youtube-dl.zip
chmod a+x youtube-dl
```
But I forgot the fact that the zipped package is already provided in the tarballs we download. So yeah, when we download the release tarballs we're not really compiling anything other than `CONTRIBUTING.md` and `docs/supportedsites.md`.
youtube-dl clearly falls into "require compile" so I'm not sure why that quote is an argument against bottling.
As for merging, I personally preferred `brew pull` over clicking the merge button since it's safer (checks malformed title and such), and bottling or not doesn't make a huge difference for `brew pull`. YMMV.
> All three bottles end up identical
That's true for any pure Python wheel. There's not much to compile, sure, but the end result is still very different from source form, and I don't think there's any guideline that says we only make bottles when there's heavy compilation involved.
RTD semi-randomly "sanitizes" my Sphinx conf.py, leading to failure related to local extension discovery
========================================================================================================
## Details
* Project URL: https://readthedocs.org/projects/storyboard
* Build URL (if applicable): https://readthedocs.org/projects/storyboard/builds/5168349/
* Read the Docs username (if applicable): zmwangx
## Expected Result
Compare the build https://readthedocs.org/projects/storyboard/builds/5168349/ (a failed build) to https://readthedocs.org/projects/storyboard/builds/5168073/ (a successful build). Both builds were for the exact same commit, except the former is for latest and the latter is for stable.
In the successful build, if you check `cat conf.py`, you'll see that my `conf.py` is used, which, in particular, includes the following excerpt:
```py
sys.path.insert(0, os.path.abspath('../numpydoc'))
extensions = [
'sphinx.ext.autodoc',
'numpydoc',
'sphinx.ext.coverage',
'sphinx.ext.doctest',
'sphinx.ext.autosummary',
]
```
Here the inserted path is responsible for surfacing the `numpydoc` extension. This `conf.py` is expected.
## Actual Result
Instead, in the failed build, the `conf.py` appears "sanitized":
```py
needs_sphinx = '1.1'
extensions = ['sphinx.ext.autodoc', 'sphinx.ext.pngmath', 'numpydoc',
'sphinx.ext.intersphinx', 'sphinx.ext.coverage',
'sphinx.ext.autosummary', 'matplotlib.sphinxext.plot_directive']
...
###########################################################################
# auto-created readthedocs.org specific configuration #
###########################################################################
...
```
In particular, my path insertion
```py
sys.path.insert(0, os.path.abspath('../numpydoc'))
```
is gone, so the `numpydoc` extension can no longer be located, resulting in an error
```
ExtensionError: Could not import extension numpydoc (exception: No module named numpydoc)
```
What's extremely frustrating is, as you can see, my `conf.py` gets "sanitized" semi-randomly, even when the exact same revision is built multiple times. The "sanitization" happens the great majority of the time. I guess it depends on the build server?
Anyway, I wish there were a way to tell RTD to respect my `conf.py`.