New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove vibe.d dependency: It's fetched even when unused #55
Comments
Sure! Can do number 2. And will do as soon as I get around to it. As long as there’s a command line that can be run from root that runs all tests then I have no issues with having the vibed tests in a different dub.json |
Hi, how are things going? I have a release candidate of my game ready, it's refactored to use the current optional 1.2.1. Before I push that to my stable repo, I'd love optional to drop the vibe.d dependency from its main dub file, so that packagers of the release need not be concerned with vibe.d or its dependencies. If you're super short on time, I'd be up to do the work for you; feel free to give me pointers on how exactly you'd like to run your unittests. |
Hey! Thanks fo the offer - I have indeed been very out of D lately and short on time :p But anyway, I've released a version now with a different folder for the compattests. Let me know if this works or if this now causes different issues! |
Excellent, thank you for the immediate resolution! optional 1.3.0 works great: It doesn't fetch vibe.d nor stdx-allocator anymore, and usercode written for optional 1.2.1 works just as well with 1.3.0. |
Hehe, immediate after the second ping 6 months after the first :p But I'll take compliment 😊 Glad it works! |
Package optional 1.2.1 depends optionally on vibe.d for the test configuration: One of optional's goals is good vibe.d-interop. There is no such dependency in release configuration.
As a result, even when we build package optional for release and not for testing, dub will nonetheless always fetch vibe.d and its dependency stdx-allocator.
libcrypto-1_1.dll
and other such Windows binaries that make for 4 MB by themselves already.The fundamental problem is in dub's design. Its only FAQ is: Why are dependencies downloaded that belong to configurations that are not being built? At dependency-downloading time, dub doesn't yet know which configuration we want.
Maybe the Linux distro packagers can mock vibe.d to satisfy dub's desire to fetch optional's unused dependency when building optional. But it feels like we should fix this before it comes to distribution. :-) Thus:
dub.json
that sits in a subtree of optional and thus is ignored for scanning the dependencies? Then the main optional doesn't have to depend on vibe.d in any configuration, and dub will then be happy without vibe.d.The text was updated successfully, but these errors were encountered: