Thread overview
dub fetching dependencies for wrong configuration(s)
Oct 04, 2020
Anonymouse
Oct 04, 2020
ikod
Oct 04, 2020
Andre Pany
Oct 04, 2020
ikod
Oct 27, 2020
Anonymouse
Oct 27, 2020
ikod
Oct 27, 2020
Anonymouse
Oct 28, 2020
ikod
Oct 28, 2020
Anonymouse
Oct 29, 2020
ikod
October 04, 2020
My project depends on the requests dub package, which has two build configurations; one with an extra vibe-d dependency, one without (default).

    "configurations": [
        {
            "name": "std"
        },
        {
            "name": "vibed",
            "versions": ["vibeD"],
            "dependencies": {
                "vibe-d": ">=0.8.0"
            }
        }
    ],

I only ever use the default "std" configuration, but dub always pulls the additional multiple vibe-d dependencies, regardless of what I pick. Adding a subConfiguration restriction does not seem to help.

$ dub upgrade
Upgrading project in /home/zorael/src/kameloso
Fetching vibe-core 1.10.2 (getting selected version)...
Fetching memutils 1.0.4 (getting selected version)...
Fetching taggedalgebraic 0.11.18 (getting selected version)...
Fetching vibe-d 0.9.2 (getting selected version)...
Fetching botan-math 1.0.3 (getting selected version)...
Fetching stdx-allocator 2.77.5 (getting selected version)...
Fetching botan 1.12.18 (getting selected version)...
Fetching diet-ng 1.7.4 (getting selected version)...
Fetching openssl 1.1.6+1.0.1g (getting selected version)...
Fetching eventcore 0.9.9 (getting selected version)...
Fetching mir-linux-kernel 1.0.1 (getting selected version)...
Fetching libasync 0.8.6 (getting selected version)...

Is there any way to stop this?
October 04, 2020
On Sunday, 4 October 2020 at 14:08:24 UTC, Anonymouse wrote:
> My project depends on the requests dub package, which has two build configurations; one with an extra vibe-d dependency, one without (default).
>
>     "configurations": [
>         {
>             "name": "std"
>         },
>         {
>             "name": "vibed",
>             "versions": ["vibeD"],
>             "dependencies": {
>                 "vibe-d": ">=0.8.0"
>             }
>         }
>     ],
>
> I only ever use the default "std" configuration, but dub always pulls the additional multiple vibe-d dependencies, regardless of what I pick. Adding a subConfiguration restriction does not seem to help.
>
> $ dub upgrade
> Upgrading project in /home/zorael/src/kameloso
> Fetching vibe-core 1.10.2 (getting selected version)...


>
> Is there any way to stop this?

AFAIK this is dub feature, which you cant't avoid easily. Naybe there are some reasons behind this feature, idk. But I'd like to avoid it too.

October 04, 2020
On Sunday, 4 October 2020 at 14:08:24 UTC, Anonymouse wrote:
> My project depends on the requests dub package, which has two build configurations; one with an extra vibe-d dependency, one without (default).
>
>     "configurations": [
>         {
>             "name": "std"
>         },
>         {
>             "name": "vibed",
>             "versions": ["vibeD"],
>             "dependencies": {
>                 "vibe-d": ">=0.8.0"
>             }
>         }
>     ],
>
> I only ever use the default "std" configuration, but dub always pulls the additional multiple vibe-d dependencies, regardless of what I pick. Adding a subConfiguration restriction does not seem to help.
>
> $ dub upgrade
> Upgrading project in /home/zorael/src/kameloso
> Fetching vibe-core 1.10.2 (getting selected version)...
> Fetching memutils 1.0.4 (getting selected version)...
> Fetching taggedalgebraic 0.11.18 (getting selected version)...
> Fetching vibe-d 0.9.2 (getting selected version)...
> Fetching botan-math 1.0.3 (getting selected version)...
> Fetching stdx-allocator 2.77.5 (getting selected version)...
> Fetching botan 1.12.18 (getting selected version)...
> Fetching diet-ng 1.7.4 (getting selected version)...
> Fetching openssl 1.1.6+1.0.1g (getting selected version)...
> Fetching eventcore 0.9.9 (getting selected version)...
> Fetching mir-linux-kernel 1.0.1 (getting selected version)...
> Fetching libasync 0.8.6 (getting selected version)...
>
> Is there any way to stop this?

The reasoning is explained here:
https://github.com/dlang/dub/wiki/FAQ#why-are-dependencies-downloaded-that-belong-to-configurations-that-are-not-being-built

While these dependencies are downloaded, they will not be part of your binary.

At the moment the only chance to avoid these additional dependencies would be to split requests into 2 dub packages. The core package which uses std, and an additional package which is based on the core package and is using vibe-d.

Kind regards
Andre

October 04, 2020
On Sunday, 4 October 2020 at 20:08:31 UTC, Andre Pany wrote:
> On Sunday, 4 October 2020 at 14:08:24 UTC, Anonymouse wrote:

> At the moment the only chance to avoid these additional dependencies would be to split requests into 2 dub packages. The core package which uses std, and an additional package which is based on the core package and is using vibe-d.
>
> Kind regards
> Andre

Thanks, Andre!
I'll split requests as you suggested (increasing minor version, so that this change will not hurt anybody who build current requests package for vibe-d).
October 27, 2020
On Sunday, 4 October 2020 at 21:00:49 UTC, ikod wrote:
> Thanks, Andre!
> I'll split requests as you suggested (increasing minor version, so that this change will not hurt anybody who build current requests package for vibe-d).

Will you make a requests-core?
October 27, 2020
On Tuesday, 27 October 2020 at 17:01:23 UTC, Anonymouse wrote:
> On Sunday, 4 October 2020 at 21:00:49 UTC, ikod wrote:
>> Thanks, Andre!
>> I'll split requests as you suggested (increasing minor version, so that this change will not hurt anybody who build current requests package for vibe-d).
>
> Will you make a requests-core?

I plan to clean requests package dependency from vibe, and make separate requests-vibe with vibe enabled config.

Is it urgent?
October 27, 2020
On Tuesday, 27 October 2020 at 21:15:35 UTC, ikod wrote:
> On Tuesday, 27 October 2020 at 17:01:23 UTC, Anonymouse wrote:
>> On Sunday, 4 October 2020 at 21:00:49 UTC, ikod wrote:
>>> Thanks, Andre!
>>> I'll split requests as you suggested (increasing minor version, so that this change will not hurt anybody who build current requests package for vibe-d).
>>
>> Will you make a requests-core?
>
> I plan to clean requests package dependency from vibe, and make separate requests-vibe with vibe enabled config.
>
> Is it urgent?

Not very, just following with interest!
October 28, 2020
On Tuesday, 27 October 2020 at 22:15:34 UTC, Anonymouse wrote:
> On Tuesday, 27 October 2020 at 21:15:35 UTC, ikod wrote:
>> On Tuesday, 27 October 2020 at 17:01:23 UTC, Anonymouse wrote:
>>> On Sunday, 4 October 2020 at 21:00:49 UTC, ikod wrote:
>>>> Thanks, Andre!
>>>> I'll split requests as you suggested (increasing minor version, so that this change will not hurt anybody who build current requests package for vibe-d).
>>>
>>> Will you make a requests-core?
>>
>> I plan to clean requests package dependency from vibe, and make separate requests-vibe with vibe enabled config.
>>
>> Is it urgent?
>
> Not very, just following with interest!

Well, I pushed fix to github. Change consist from moving vibe-d support in separate subpackage:

    "configurations": [
        {
            "name": "std"
        }
    ],
    "subPackages": [
        "./vibed/"
    ],

So if you don't use requests on top of vibe-d sockets you can leave everything as is. And you should not fetch all vibe-d dependencies(!).

If you use requests with vibe-d sockets you have to use 'requests:vibed' instead of 'requests' as dependency (and not subConfiguration)

To make this transition as painless as possible I'll create new package with major version "2" if you confirm that everything works as expected.

Thanks,
Igor
October 28, 2020
On Wednesday, 28 October 2020 at 19:34:43 UTC, ikod wrote:
> To make this transition as painless as possible I'll create new package with major version "2" if you confirm that everything works as expected.

I tried cloning requests from git and added it as a dub package, and it seems to work.

> ~/src $ rm -rf ~/.dub/packages

> ~/src $ git clone https://github.com/ikod/dlang-requests.git
> ~/src $ dub add-local dlang-requests
> Registered package: requests (version: 1.1.7+commit.4.g8e1c308)

> ~/src $ cd kameloso
> ~/src/kameloso $ dub upgrade
> Upgrading project in /home/zorael/src/kameloso
> Fetching lu 0.5.0 (getting selected version)...
> Fetching cachetools 0.3.1 (getting selected version)...
> Fetching dialect 0.9.0 (getting selected version)...
> Fetching arsd-official 8.5.2 (getting selected version)

No vibe-d downloaded!
October 29, 2020
On Wednesday, 28 October 2020 at 21:56:46 UTC, Anonymouse wrote:
> On Wednesday, 28 October 2020 at 19:34:43 UTC, ikod wrote:
>> To make this transition as painless as possible I'll create new package with major version "2" if you confirm that everything works as expected.
...
> No vibe-d downloaded!

Thanks! I bumped version to 2.0.0
And thanks Andre for idea with packages.