Start pulling pub from its own repo.

Start pulling pub from its own repo.

Pub now lives in third_party/pkg/pub (it's in pkg to make it possible to import
using "package:" imports).

R=ricow@google.com, rnystrom@google.com

Committed: https://github.com/dart-lang/sdk/commit/3d8c06c4e9a154e25fb1209b51608905755bebf4

[nweiz, 2015-05-28 21:21:55]

nweiz@google.com changed reviewers:
+ ricow@google.com, rnystrom@google.com

[Bob Nystrom, 2015-05-28 21:29:26]

Very exciting!

https://codereview.chromium.org/1165473002/diff/1/DEPS
File DEPS (right):

https://codereview.chromium.org/1165473002/diff/1/DEPS#newcode242
DEPS:242: Var("dart_root") + "/third_party/pkg/pub":
pkg_tested

https://codereview.chromium.org/1165473002/diff/1/tools/create_sdk.py
File tools/create_sdk.py (right):

https://codereview.chromium.org/1165473002/diff/1/tools/create_sdk.py#newcode232
tools/create_sdk.py:232: copytree(join(HOME, 'third_party', 'pkg', 'pub', 'lib',
'src', 'asset'),
pkg_tested

https://codereview.chromium.org/1165473002/diff/1/tools/run_pub.py
File tools/run_pub.py (right):

https://codereview.chromium.org/1165473002/diff/1/tools/run_pub.py#newcode15
tools/run_pub.py:15: PUB_PATH = os.path.join(DART_ROOT,
'third_party/pkg/pub/bin/pub.dart')
pkg_tested

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp
File utils/pub/pub.gyp (left):

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp#oldcode45
utils/pub/pub.gyp:45: 'target_name': 'pub_files_stamp',
Is anything still using this? Observatory?

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp
File utils/pub/pub.gyp (right):

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp#newcode33
utils/pub/pub.gyp:33: '../../third_party/pkg/pub/bin/pub.dart',
pkg_tested

[nweiz, 2015-05-28 21:41:48]

Code review changes

[nweiz, 2015-05-28 21:42:15]

https://codereview.chromium.org/1165473002/diff/1/DEPS
File DEPS (right):

https://codereview.chromium.org/1165473002/diff/1/DEPS#newcode242
DEPS:242: Var("dart_root") + "/third_party/pkg/pub":
On 2015/05/28 21:29:26, Bob Nystrom wrote:
> pkg_tested

Done.

https://codereview.chromium.org/1165473002/diff/1/tools/create_sdk.py
File tools/create_sdk.py (right):

https://codereview.chromium.org/1165473002/diff/1/tools/create_sdk.py#newcode232
tools/create_sdk.py:232: copytree(join(HOME, 'third_party', 'pkg', 'pub', 'lib',
'src', 'asset'),
On 2015/05/28 21:29:26, Bob Nystrom wrote:
> pkg_tested

Done.

https://codereview.chromium.org/1165473002/diff/1/tools/run_pub.py
File tools/run_pub.py (right):

https://codereview.chromium.org/1165473002/diff/1/tools/run_pub.py#newcode15
tools/run_pub.py:15: PUB_PATH = os.path.join(DART_ROOT,
'third_party/pkg/pub/bin/pub.dart')
On 2015/05/28 21:29:26, Bob Nystrom wrote:
> pkg_tested

Done.

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp
File utils/pub/pub.gyp (left):

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp#oldcode45
utils/pub/pub.gyp:45: 'target_name': 'pub_files_stamp',
On 2015/05/28 21:29:26, Bob Nystrom wrote:
> Is anything still using this? Observatory?

I removed the observatory dependency on this.

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp
File utils/pub/pub.gyp (right):

https://codereview.chromium.org/1165473002/diff/1/utils/pub/pub.gyp#newcode33
utils/pub/pub.gyp:33: '../../third_party/pkg/pub/bin/pub.dart',
On 2015/05/28 21:29:25, Bob Nystrom wrote:
> pkg_tested

Done.

[Bob Nystrom, 2015-05-28 21:43:12]

LGTM!

[ricow1, 2015-05-29 05:55:20]

ricow@google.com changed reviewers:
+ floitsch@google.com

[ricow1, 2015-05-29 05:55:22]

+floitsch
The changes for pulling it in LGTM

As I said when we chatter about this, there are downsides to this (I know that
there are upsides as well, especially for community involvement)
Test changes impacted by the vm becomes much more cumbersome, example from
yesterday:
https://codereview.chromium.org/1159983005/
Yesterday that was a one line change in one repo
With this:
  Make a change in the pub repo
  Wait for bots to go green on that
  Roll deps in the main repo
  Wait for the main bots to go green on that
  if they don't:
    investigate which pub changes that had not been rollel caused this.
    Update status files or land another change in pub repo, rinse repeat

I am not saying don't do this, I am just saying that we should be aware. In
reality, I think what will happen instead of the above is that a suppression
will be made and a bug filed to fix it, i.e., we move the burden from the vm
team to the pub team, with the vm team actually doing just as much work but
without fixing it.

[Bob Nystrom, 2015-05-29 15:53:16]

On 2015/05/29 05:55:22, ricow1 wrote:
> +floitsch
> The changes for pulling it in LGTM
> 
> As I said when we chatter about this, there are downsides to this (I know that
> there are upsides as well, especially for community involvement)
> Test changes impacted by the vm becomes much more cumbersome, example from
> yesterday:
> https://codereview.chromium.org/1159983005/
> Yesterday that was a one line change in one repo
> With this:
>   Make a change in the pub repo
>   Wait for bots to go green on that
>   Roll deps in the main repo
>   Wait for the main bots to go green on that
>   if they don't:
>     investigate which pub changes that had not been rollel caused this.
>     Update status files or land another change in pub repo, rinse repeat
> 
> I am not saying don't do this, I am just saying that we should be aware. In
> reality, I think what will happen instead of the above is that a suppression
> will be made and a bug filed to fix it, i.e., we move the burden from the vm
> team to the pub team, with the vm team actually doing just as much work but
> without fixing it.

Yes, this is a totally valid concern.

In general, I think repository boundaries work much like any other interface or
modularity boundary in software. If the things on either side of the line are
relatively independent, the interface makes it easy for people working on one
side to ignore stuff on the other one. If they are tightly coupled and a change
in one side often necessitates a change to the other side, then the boundary is
more of a hindrance than a help.

Finding the right seams—the right set of independent repositories in this
case—that maximize our overall productivity is hard. It will probably take a few
iterations before we get it "right" and right will likely change over time.

- bob

[ricow1, 2015-05-29 16:13:31]

On 2015/05/29 15:53:16, Bob Nystrom wrote:
> On 2015/05/29 05:55:22, ricow1 wrote:
> > +floitsch
> > The changes for pulling it in LGTM
> > 
> > As I said when we chatter about this, there are downsides to this (I know
that
> > there are upsides as well, especially for community involvement)
> > Test changes impacted by the vm becomes much more cumbersome, example from
> > yesterday:
> > https://codereview.chromium.org/1159983005/
> > Yesterday that was a one line change in one repo
> > With this:
> >   Make a change in the pub repo
> >   Wait for bots to go green on that
> >   Roll deps in the main repo
> >   Wait for the main bots to go green on that
> >   if they don't:
> >     investigate which pub changes that had not been rollel caused this.
> >     Update status files or land another change in pub repo, rinse repeat
> > 
> > I am not saying don't do this, I am just saying that we should be aware. In
> > reality, I think what will happen instead of the above is that a suppression
> > will be made and a bug filed to fix it, i.e., we move the burden from the vm
> > team to the pub team, with the vm team actually doing just as much work but
> > without fixing it.
> 
> Yes, this is a totally valid concern.
> 
> In general, I think repository boundaries work much like any other interface
or
> modularity boundary in software. If the things on either side of the line are
> relatively independent, the interface makes it easy for people working on one
> side to ignore stuff on the other one. If they are tightly coupled and a
change
> in one side often necessitates a change to the other side, then the boundary
is
> more of a hindrance than a help.
> 
> Finding the right seams—the right set of independent repositories in this
> case—that maximize our overall productivity is hard. It will probably take a
few
> iterations before we get it "right" and right will likely change over time.
> 
> - bob
+1 to all the above, this is one case that I don't know if it will be a benefit
because of increased independence, or a drag because of cross boundary changes

[nweiz, 2015-05-29 21:50:25]

Committed patchset #2 (id:10001) manually as
3d8c06c4e9a154e25fb1209b51608905755bebf4 (presubmit successful).