Breaking-Change-Request: Forbid publishing of packages with git or third party hosted dependencies

[jonasfj]

It is currently possible to publish packages to pub.dartlang.org which have
dependencies that are fetched from git or a third party hosted pub repository.

Rationale: This is undesirable as the contents of these dependencies can change, moreover, they might be unavailable at some point in the future. This could happen as a
result of someone deleting or changing their github repo- or username.

Impact: As of April 8th there was around 52 packages whose latest version
had a dependency on a git repository or third-party package repository. About
half of these were last published more than a year ago (before Dart 2.0).

Currently, published packages will remain, we merely forbid publishing of
new packages with git or third party pub repository dependencies. We may
remove these at a later date.

Mitigation: Git dependencies have largely been used to fork an existing
package, and then depend on the git repository until upstream merges the patch.
Going forward we recommend that forked packages be published under a new name
(for example, <github username>_<packageName>).

[travissanderson-wf]

Could this be opt-in (or at least opt-out) for packages published to a private pub repository? If it was opt-in it would be non-breaking for that use case while still giving the gentle suggestion that git dependencies aren't the greatest idea

[jonasfj]

@travissanderson-wf, I think we will enforce this server-side on pub.dartlang.org, that way it will not affect third-party pub repositories.

[travissanderson-wf]

Oh I see, I thought it was getting baked into the pub CLI since the issue was on the SDK. Thanks!

[jonasfj]

It might be worthwhile to make the pub CLI command print a warning if publishing with a git dependency (since third party pub repositories might benefit from that). But I see no reason to enforce it on the client, we have to enforce it server-side regardless, and only enforcing server-side gives us more flexibility.

[travissanderson-wf]

As long as the client forwards the failure reason received from the server, that is true

[aadilmaan]

Request: @Hixie @matanlurey @dgrove for approval.

[Hixie]

seems reasonable

[dgrove]

LGTM

[jaumard]

I using git hosted dependency for the use case @jonasfj describe which is I made a PR on flutter camera plugin and need that for my package to work. So I'm using my fork directly as dependency.

Going forward we recommend that forked packages be published under a new name
(for example, _).

So pub will become trash with mostly _ not maintained anymore because only use until that PR was merged :/ and as we can't delete once it's published it will become a nightmare after some time quick imho

[jonasfj]

@jaumard, yes, this is the downside, but usage of git dependencies in pub packages is not common, so it's unlikely to create a lot of unmaintained packages.

Alternatively, you could also wait until the patch has landed upstream. Or vendor the patched dependency in lib/src/.../. But publishing as something like <github username>_<packageName> will at-least make it clear that the package is forked. And you can request a package to be flagged discontinued by filling an issue (at some point we'll probably have a self-serve solution for this too).

[pschiffmann]

I recently started to use a git hosted package to keep my preferred lint rules in sync across packages: https://github.com/pschiffmann/pedantic-pschiffmann.dart

In my packages, I add this to my pubspec.yaml:

dev_dependencies:
  pedantic_pschiffmann:
    git:
      url: https://github.com/pschiffmann/pedantic-pschiffmann.dart
      ref: 97fab6223f4e367ccfade79f998bfc137e2e6131

... and this to my analysis_options.yaml: include: package:pedantic_pschiffmann/analysis_options.yaml

This is not a package I'd publish on pub, because my lint rules are personal preference and not very useful to someone else; but after I change my mind and add or remove a rule, I want to do so in all my projects.

Of course, I can just comment out that dependency before publishing to pub, I don't have strong feelings about this. I just thought I'd share my setup. And if you believe it's a legitimate use case for git dependencies, maybe you could continue to allow them in dev_dependencies?

[jonasfj]

You can find many people who publish their personal linter preferences on npm :)

I am inclined to not care about what goes into dev_dependencies as this is ignored when using the package.