dart - where should pubspec and how many with multiple apps -

suppose there need project 3 libraries , 2 apps. pub documentation i'm choosing structure below. apps different enough, though, desirable have own directory. documentation @ (http://pub.dartlang.org/doc/#adding-a-dependency) says put pubspec.yaml file @ top-level. top-level in context below project folder?

if there 1 pubspec , @ /project level , shared libs, wouldn't mean users of of libs not apps unnecessarily require packages (like good_stuff , big_stuff)?

/project     /app         /app1    (uses l1, package:good_stuff)         /app2    (uses l1, l2, l3, package:big_stuff)     /lib         /l1         /l2      (uses package:pathos/path.dart)         /l3      (uses l1 , l2)         /src             /l1             /l2             /l3 

so, given desired setup, how many pubspec's , created satisfy these dependencies.

packages

you should put pubspec.yaml file in top level of package. in pub, package largest unit of self-contained code, , contains libraries, executables, examples, documentation, tests, , tools required package live itself.

in pub, there loosely 2 types of packages:

• library packages, library in conventional sense, , intended used other packages.
• application packages consumers of other packages , define application can run on command line, server, web, or elsewhere.

these loose definitions because library packages might have executables, , application packages might have reusable libraries useful in other applications.

generally, want try make project out of several discrete components, can change , re-used individually. in contrast making 1 package parts of application.

your project

i recommend have following structure:

/project   /app1     - pubspec.yaml   /app2     - pubspec.yaml   /mechanics     - pubspec.yaml     /lib       l1.dart       l2.dart       l3.dart       /src         ... 

here you'd have 2 application packages , 1 library package.

a few notes:

• you can refer mechanics package path dependencies

• you want project/ top top level if you're anticipating keeping whole project bundled (say if you're selling it.) if anticipate app1 , app2 living separately, don't need project/ @ all.

• you can totally make l1, l2, , l3 own packages if feel can live enough separately. in case, make them own package.

see also:

• creating package
• package layout