digitalmars.D.learn - dub fetching dependencies for wrong configuration(s)

Anonymouse (34/34) Oct 04 2020 My project depends on the requests dub package, which has two

ikod (4/27) Oct 04 2020 AFAIK this is dub feature, which you cant't avoid easily. Naybe
Andre Pany (11/45) Oct 04 2020 The reasoning is explained here:

ikod (5/12) Oct 04 2020 Thanks, Andre!

Anonymouse (2/6) Oct 27 2020 Will you make a requests-core?

ikod (4/10) Oct 27 2020 I plan to clean requests package dependency from vibe, and make

Anonymouse (2/13) Oct 27 2020 Not very, just following with interest!

ikod (22/37) Oct 28 2020 Well, I pushed fix to github. Change consist from moving vibe-d

Anonymouse (4/18) Oct 28 2020 I tried cloning requests from git and added it as a dub package,

ikod (4/9) Oct 28 2020 Thanks! I bumped version to 2.0.0

Anonymouse <zorael gmail.com> writes:

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?

Oct 04 2020

ikod <igor.khasilev gmail.com> writes:

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.

Oct 04 2020

Andre Pany <andre s-e-a-p.de> writes:

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

Oct 04 2020

ikod <igor.khasilev gmail.com> writes:

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).

Oct 04 2020

Anonymouse <zorael gmail.com> writes:

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?

Oct 27 2020

ikod <igor.khasilev gmail.com> writes:

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?

Oct 27 2020

Anonymouse <zorael gmail.com> writes:

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!

Oct 27 2020

ikod <igor.khasilev gmail.com> writes:

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

Oct 28 2020

Anonymouse <zorael gmail.com> writes:

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!

Oct 28 2020

ikod <igor.khasilev gmail.com> writes:

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.

Oct 28 2020

D Programming

C/C++ Programming

Other

digitalmars.D.learn - dub fetching dependencies for wrong configuration(s)