Pub: how to deal with circular dependencies

[Ladislav Thon]

Hi guys,

since Pub is coming along rather nicely, I figured I will take a stab at making some of my libraries proper packages. I didn't get far, though. Imagine a situation like this:

1. I have a small package, say it's called dartlings (because it really is, and it's called like that since december 2011). It has no dependencies.

2. I have another package called detester. It depends on dartlings (among other packages, but they aren't important here). So far, no problem.

3. Ooh, but dartlings actually does depend on something... Specifically, the core library has no dependencies, but the tests do -- they depend on detester (the dependency is declared like 'git: file://...').

If I try to 'pub install' in the dartlings directory, I get

  Package 'dartlings' is depended on from both sources 'root' and 'git'.

I do somewhat understand what that means, but I have no idea how to deal with it. Any ideas?

LT

[Nathan Weizenbaum]

This should be supported. I've filed http://code.google.com/p/dart/issues/detail?id=5300 to track it.

LT

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Ladislav Thon]

If you want to support circular dependencies, by all means go ahead. I personally think that dependencies should form a DAG and I strive for that in my libraries.

So here's another approach that could solve my problem -- the notion of "development dependencies" or "test dependencies". It isn't that uncommon, you can find them e.g. in Ruby world or Java world (maybe elsewhere too). They would be only symlinked into the "packages" directory in the "test" directory (which would mean that it couldn't be a symlink to the root "packages" directory anymore, but I see that only as a cosmetic issue).

Or another option (more complicated and more questionable) -- something like a "scope" of a dependency (that's actually what we have in Java/Maven world):

dependencies:
  detester:
    git: ...
    scope: test

It would be a list of directories where the package would be symlinked (possible values: root, bin, example, test, web -- I think that's all we have). Unset value means "all".

Both options also have an additional benefit of self-documentation.

Ideas?

LT

[Bob Nystrom]

On Thu, Sep 20, 2012 at 9:45 PM, Ladislav Thon <lad...@gmail.com> wrote:

If you want to support circular dependencies, by all means go ahead. I personally think that dependencies should form a DAG and I strive for that in my libraries.

Right. Non-cyclic graphs are generally happier graphs and I think it's good to aim for that. At the same time, completely disallowing cycles is a harsh limitation in the couple of cases where it does turn out to be useful. Also, Dart allows cyclic library imports, so it would feel strange to disallow that at the package level.

So here's another approach that could solve my problem -- the notion of "development dependencies" or "test dependencies". It isn't that uncommon, you can find them e.g. in Ruby world or Java world (maybe elsewhere too).

Dev dependencies are definitely on our radar. I don't think there's a bug yet (and if you'd like, feel free to file one), but I believe it's something we intend to support.

They would be only symlinked into the "packages" directory in the "test" directory (which would mean that it couldn't be a symlink to the root "packages" directory anymore, but I see that only as a cosmetic issue).

Clever! I haven't thought much about dev deps yet, but that does make sense.

Or another option (more complicated and more questionable) -- something like a "scope" of a dependency (that's actually what we have in Java/Maven world):

dependencies:
  detester:
    git: ...
    scope: test

It would be a list of directories where the package would be symlinked (possible values: root, bin, example, test, web -- I think that's all we have). Unset value means "all".

Both options also have an additional benefit of self-documentation.

Ideas?

That's interesting, but also potentially complex and confusing. Whenever possible, I like to start simple and only add complexity when we distinctly feel the pain of its absence. I try to fight my own natural tendency to overengineer everything. :)

- bob

[Ladislav Thon]

Also, Dart allows cyclic library imports, so it would feel strange to disallow that at the package level.

Right. They should be supported.

 

So here's another approach that could solve my problem -- the notion of "development dependencies" or "test dependencies". It isn't that uncommon, you can find them e.g. in Ruby world or Java world (maybe elsewhere too).

Dev dependencies are definitely on our radar. I don't think there's a bug yet (and if you'd like, feel free to file one), but I believe it's something we intend to support.

Great to hear! Filed http://dartbug.com/5358.

LT

[Bob Nystrom]

Thanks!

- bob

--