Package dependency by path in pubspec.yaml without generating an absolute path in the lock file?

[Nik Graf]

In the documentation it's recommended to check the lockfiles into source control.

* http://pub.dartlang.org/doc/glossary.html#application-package

* http://pub.dartlang.org/doc/#updating-a-dependency

* http://stackoverflow.com/questions/16136739/in-dart-and-pub-should-i-add-pubspec-lock-to-my-gitignore

When I specify a required package via a relative path in pubspec.yaml an absolute path is generated in the lockfile. This requires the exact same location of the project for everyone who is working on the application.

Is there a way to avoid this and still have the imported library in the same repository?

Example:

pubspec.yaml

name: application
dependencies:
  google_blossom_0_0_0_api:
    path: ../dart_blossom_0_0_0_api_client

pubspec.lock

packages:
  google_blossom_0_0_0_api:
    description:
      path: "/Users/nikolausgraf/projects/blossom/dart/application/../dart_blossom_0_0_0_api_client"
      relative: true
    source: path
    version: "0.1.0"

[Matthew Butler]

Nik,

Also see this point about the 'Path' dependency:

Path dependencies are useful for local development, but do not play nice with sharing code with the outside world. It’s not like everyone can get to your file system, after all. Because of this, you cannot upload a package to pub.dartlang.org if it has any path dependencies in its pubspec.

http://pub.dartlang.org/doc/dependencies.html#path-packages 

Key point there is 'local' development as well. 

That said however, with proper version constraints in pubspec now, I'm not entirely sure it is still required to include your pubspec.lock file for application development. I think this rule was originally devised prior to full version constraints landing in pub (though I'm not totally certain on that now), as the lock file was being used to constrain the versions. In particular the 'path' dependencies can't provide version constraints properly in the lockfile. (You may have google_blossom_0_0_0_api v. 0.1.0 in ../ on your machine but maybe another developer has patched google_blossom_0_0_0_api to v. 0.1.1 after a bug fix that hasn't been distributed yet or that you haven't downloaded locally yourself).

Matt

[Nik Graf]

Thanks for the fast response Matt.

I think I need to rephrase the questions:

Is there a good way to share code between multiple applications which live in the same repository?

We have 2 applications and need to share code between them. Ideally we would like to keep everything in the same repository just to keep it simple.

[Bob Nystrom]

On Fri, Jun 21, 2013 at 11:05 AM, Nik Graf <n...@blossom.io> wrote:

When I specify a required package via a relative path in pubspec.yaml an absolute path is generated in the lockfile. This requires the exact same location of the project for everyone who is working on the application.

Oh, curses, I didn't consider that case.

You're exactly right. Pub isn't doing the right thing here. Can you file a bug?

Thanks!

- bob

[Bob Nystrom]

On Fri, Jun 21, 2013 at 11:26 AM, Matthew Butler <butler....@gmail.com> wrote:

That said however, with proper version constraints in pubspec now, I'm not entirely sure it is still required to include your pubspec.lock file for application development.

It's still useful. Your pubspec usually constrains to a range of versions. With application packages, it often has no constraint at all. Your lockfile pins it to a single concrete version.

Cheers!

- bob

[Nik Graf]

Thanks Bob!

You can find the issue here: https://code.google.com/p/dart/issues/detail?id=11441

best regards

Nik

[Bob Nystrom]

Thank you!

If you need a workaround for now, one fix is to use single version constraints in your regular pubspec.yaml. That will ensure everyone are your team gets the same version for each dependency. Then you don't have to check in your lockfile to source control.

Cheers!

- bob

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
 
 

[Seth Ladd]

Nik and I chatted about this today. If I may, I'd like to share what we talked about to provide context and (hopefully) clarity. :)

Nik has multiple Web UI apps in a single repo. They all share a library. What's the best way to do this?

Nik had a directory layout like this:

repo

  - shared

  - app1

    - web

    - lib

    - build.dart

  - app2

    - web

    - lib

    - build.dart

  - etc

I suggested to re-org his directory into this:

repo

  - lib

    - shared_lib

  - web

    - app1

     - index.html

    - app2

     - index.html

  - build.dart

Inside build.dart, Nik can compile both app1/index.html and app2/index.html. Each will be dumped into their own appX/out directory, so he'll still get clean self-contained apps. And, every directory inside of web/ can see lib/ via package: imports.

I *think* this captured it. @Nik can correct me. :)

[jim.trainor.kanata]

I risk sounding like a broken record here... but... I think it's a mistake IMHO to require developers to dump all their code under a single "lib" directory.� It is contrary to Dart's mission of support for "large scale web app development".

This is a concern for deployment of packaged code.� But other than that, it shouldn't make any difference.� The VM and Dart2JS don't care what path they find your code on.� The same applies to any compiler, linker, debugger, web server, editor, IDE, build tool, or you-name-it-development-tool that I can recall ever using.� These restrictions normally appear only when it come times to deploy software. e.g. a war file has a particular structure, an RPM has particular structure, etc.

Seth Ladd

15 July, 2013 8:24 PM

Nik and I chatted about this today. If I may, I'd like to share what we talked about to provide context and (hopefully) clarity. :)

Nik has multiple Web UI apps in a single repo. They all share a library. What's the best way to do this?

Nik had a directory layout like this:

repo

� - shared

� - app1

� � - web

� � - lib

� � - build.dart

� - app2

� � - web

� � - lib

� � - build.dart

� - etc

I suggested to re-org his directory into this:

repo

� - lib

� � - shared_lib

� - web

� � - app1

� � �- index.html

� � - app2

� � �- index.html

� - build.dart

Inside build.dart, Nik can compile both app1/index.html and app2/index.html. Each will be dumped into their own appX/out directory, so he'll still get clean self-contained apps. And, every directory inside of web/ can see lib/ via package: imports.

I *think* this captured it. @Nik can correct me. :)

--
For other discussions, see https://groups.google.com/a/dartlang.org/

�

For HOWTO questions, visit http://stackoverflow.com/tags/dart

�

To file a bug report or feature request, go to http://www.dartbug.com/new

�
�

[Bob Nystrom]

On Mon, Jul 15, 2013 at 5:24 PM, Seth Ladd <seth...@google.com> wrote:

Inside build.dart, Nik can compile both app1/index.html and app2/index.html. Each will be dumped into their own appX/out directory, so he'll still get clean self-contained apps. And, every directory inside of web/ can see lib/ via package: imports.

This is a good workaround, but I think relative path dependencies should also directly support the first directory structure too. When #11441 is fixed, it should work fine.

What Nik wants to do here was always my intention. It was just an oversight on my part that the lockfile contains an absolute path, which prevents sharing projects that use relative path dependencies.

- bob