Skip to content
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

Closed
SimonN opened this issue May 11, 2021 · 5 comments
Closed

Remove vibe.d dependency: It's fetched even when unused #55

SimonN opened this issue May 11, 2021 · 5 comments

Comments

@SimonN
Copy link
Contributor

SimonN commented May 11, 2021

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.

  • The fetching of all dependencies of the optional-using program takes longer.
  • When a Linux distribution maintainer packages the optional-using program, he must separately package all dependencies. Reason: Most distributions forbid internet access when building a package from the recipe. Result: Extra workload for the maintainer.
  • The Linux distribution packaging becomes much fatter because vibe.d and its dependencies must be included to satisfy dub at build time. vibe.d is fat! Its source is 12 MB to 14 MB, the source comes with, e.g., 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:

  • Can you remove optional's optional dependency on vibe.d?
  • Or can you move the vibe.d-dependent tests to a separate 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.
@aliak00
Copy link
Owner

aliak00 commented May 14, 2021

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

@SimonN
Copy link
Contributor Author

SimonN commented Oct 11, 2021

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.

@aliak00
Copy link
Owner

aliak00 commented Oct 12, 2021

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!

@SimonN
Copy link
Contributor Author

SimonN commented Oct 12, 2021

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.

@SimonN SimonN closed this as completed Oct 12, 2021
@aliak00
Copy link
Owner

aliak00 commented Oct 13, 2021

Hehe, immediate after the second ping 6 months after the first :p But I'll take compliment 😊 Glad it works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants