Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
> Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub.

I solved this by adding
"libraryName" : {"path" : "relative/path/to/library"}

to the dependency block

On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
> Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub.

you can depend on ~master as a version, I'm not sure if you have to tell it to refresh what is has.

On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
> Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub.

What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes.

On Saturday, 5 January 2019 at 15:17:28 UTC, Mike Parker wrote:
> On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
>> Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub.
>
> What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes.

Alternatively, I sometimes use the path to the library rather than a version specification in the package recipe. With the SDLang format:

dependency mylib path="path/to/lib"

On Sat, 05 Jan 2019 13:01:24 +0000, Russel Winder wrote:
> Dub seems to have the inbuilt assumption that libraries are dependencies
> that do not change except via a formal release when you developing an
> application.
> Clearly there is the workflow where you want to amend the library but
> not release as a part of developing an application. Does Dub have a way
> of doing this, I haven't been able to infer one to date. But I am a
> beginner at Dub.

There are a few ways to do this:

1. Path dependency, as Alex mentioned.
2. Different build configurations. The same source code has two different
build targets; the executable doesn't depend on the library. Or, with
enough bludgeoning, you can make the executable depend on the library.
3. Subprojects.
4. dub add-local on the library, as Mike Parker mentioned.

I wouldn't depend on ~master because (a) that won't change until you commit stuff and (b) it might require also running dub upgrade to get the new source code.

The subproject way of doing things:

---
# dub.sdl
name "myproject"
targetType "none"
# So we build the child projects
dependency "myproject:lib" version="*"
dependency "myproject:exe" version="*"
# To define the child projects
subPackage "./lib"
subPackage "./exe"
---

---
# exe/dub.sdl
name "exe"
dependency "myproject:lib" version="*"
targetType "executable"
---

This will intuit a project structure like:

  dub.sdl
  exe/
    dub.sdl
    src/
  lib/
    dub.sdl
    src/

But if you prefer, you can modify that with "sourcePaths" in the subpackage dub.sdls.

On Sat, 05 Jan 2019 17:44:27 +0000, Neia Neutuladh wrote:
> 2. Different build configurations. The same source code has two different build targets; the executable doesn't depend on the library. Or, with enough bludgeoning, you can make the executable depend on the library.

Hit 'send' too soon.

The build configuration way would be:

---
# dub.sdl
configuration "exe" {
  targetType "executable"
}
configuration "lib" {
  targetType "staticLibrary"
  excludedSourceFiles "src/cli/*"
}
---

Then you'd build with:

    dub build --config=lib
    dub build --config=exe

To make this version of things yield an executable depending on a library, you'd use something like:

---
# dub.sdl
configuration "exe" {
  targetType "executable"
  excludedSourceFiles "src/lib/*"
  importPaths "src/lib"
  libs "-L." "-L-l:libmyproject.so"
}
configuration "lib" {
  targetType "sharedLibrary"
  excludedSourceFiles "src/cli/*"
}
---

The one advantage of this is being able to use shared libraries. It's awkward.

On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
> Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub.

I use submoduals in git and then subpackage in dub. That doesn't help with packages I don't maintain but want to contribute back to because I don't submodual those in.

I actually wish submoduals got more attention and was the expected way to manage dependencies.

On 2019-01-05 16:17, Mike Parker wrote:

> What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes.

The problem with that is that will affect all projects on the machine using that dependency. I think the approach mentioned by Alex is the best.

-- 
/Jacob Carlborg