I definitely vote for the second, but it needs to throw a clear warning. Essentially, just because some package hasn’t updated their Juno.jl progress meter bindings and threw an upper bound doesn’t mean that there should be an error for Juno as a whole. Instead, the package’s link to the Juno verse should be severed (with a clear error thrown to the user. I can forsee a lot of bug reports which are difficult to understand, only to find out that the optional dependency mechanism was just disabling the code).
The issue usually isn’t able enabling modules, it’s usually about selectively installing dependencies. Usually binary dependencies are the issue. If you’re able to install everything, at that point you don’t really care.
Let me give some DiffEq-verse examples. JLD doesn’t always build right on HPCs, since some of them use ancient CentOS versions and may have old HDF5 modules which also cause difficulties. This will throw a build error and Pkg will end up not playing nicely with you. To get around this, you want to be in a position where Pkg never adds/tries to build JLD at all. Some plotting libraries have these difficulties too. So you want to do is grab the minimum setup of the package (usually a Julia-only version) which will work on the cluster, while Pkg is trying to throw everything else at you and error, even though you’re looking to ignore all of the JLD stuff anyways. This is a problem because one dependency that cannot build/precompile means that the whole package won’t work (without fussing with the source) given the current setup.
This is another reason why I think of it as a “if the user has X installed, add functions, otherwise delete this part”. REQUIRE should just check if it is installed, and if it is, use it and add the functionality, precompiled and all. What we’re trying to avoid is crippling large packages which offer a lot, but cannot be used because some small dependency is causing a problem (especially when then extra functionality isn’t something used by the majority of users). Other people may care more about the “purity in the number of true dependencies”, but I just care about this because required dependencies can cause the entire package to fail to precompile.