[META] allow multiple packages to be posted to a single package name

[lukepighetti]

I've been thinking a lot about the issues caused by package name ownership.

1. Squatting
2. Bit rotting a package
3. Zombifying a package for exposure instead of passing it on to a new maintainer

This could be resolved if we allow multiple packages to be published under a single name.

Example:

flutter_compass/hemanthrajv flutter_compass/lukepighetti

How would this work?

My proposal would be that anyone can create a package name, and they become the default, so in this case

flutter_compass is the same as flutter_compass/hemanthrajv because they created it.

But then I can come in later and publish my version as flutter_compass/lukepighetti

This avoids situations such as this https://github.com/hemanthrajv/flutter_compass/issues/43 where a package is no longer maintained, is missing features, and my only solution is to clutter up the pub namespace with a fork of an existing package.

[jonasfj]

flutter_compass/hemanthrajv flutter_compass/lukepighetti

This seems a lot like package namespaces in reverse.

When building verified publishers we did consider creating package namespaces. I suppose it's something we could reconsider in the future.

There are many reasons against this and design choices that can be taken.

• If namespaces are part of the import-declaration in myfile.dart (or specified in pubspec.yaml), then:
  • packages can't be moved from one namespace to another without all dependencies having to migrate,
  • In addition you get all the problems associated with having multiple versions of the same package, notably packages from different namespaces might have largely the same type names, and functionality, but an object from one package is not an implementation of the interface from another package. Creating weird errors like SomeObject from package:namespaceA/pkgfoo/foo.dart is not an instance of SomeObject package:namespaceB/pkgfoo/foo.dart, which will might be shortened and presented as SomeObject is not an instance of SomeObject (especially if you SomeObject as return value from a 3rd package).
• If namespaces are not part of the import-declaration in myfile.dart (or specified in pubspec.yaml), then:
  • as packages from different namespaces starts to deviate we'll various compatibility bugs.

Personally, I would sort of like the option to have multiple versions of the same package, at-least multiple major versions of the same package. As well as the ability to rename package dependencies in pubspec.yaml, but such features have many edge cases and can cause many weird problems.

So there is an argument that we should accept the downside of cluttering up the pub namespace with forks of existing packages. It's ugly, but consequences are not as far reaching.

Another solution I think we should consider building is tooling for vendoring packages. This also have downsides, but if I'm not exposing types from the package I'm vendoring the downside is mainly code-bloat (which you can mitigate when it becomes large enough for someone to care).

[lukepighetti]

Could this be handled by adding a vendor key in pubspec.yaml?

ie

dependencies:
  flutter_compass:
    version: ^1.6.2
    vendor: lukepighetti.com

or some shorthand

dependencies:
  flutter_compass@lukepighetti.com: ^1.6.2

either way the expectation would be to have it come through as

import 'package:flutter_compass/flutter_compass.dart

I do believe that allowing competition within a package name has some benefits.

In practice we already cherrypick git branches to try to get the features we need from people who have forked a package that is ahead of what's on pub. Why not recognize this common situation and give pub a real competitive mechanism for people to leapfrog an under-maintained package?

[ahmednfwela]

I think this is an important thing to have.

After null safety came to stable channel, many unmaintained packages became unusable because they depended on packages that were also unmaintained.

So even if you try to fork and fix a package, there is no way to publish it to pub.dev (since git dependencies aren't allowed in packages).

A recent example: https://pub.dev/packages/flutter_masked_text https://pub.dev/packages/flutter_masked_text2 https://pub.dev/packages/extended_masked_text

I think @lukepighetti suggestion is good enough, having the publisher specified in pubspec.yaml and if its not present, the initial publisher should be resolved.

And since package publishers can set a package as Discontinued, instead of hiding the package from search results, the package can be displayed with different publishers under the same name

[lukepighetti]

A fallthrough for discontinued packages is a big deal. I have discontinued packages and I would have no problem if it fell through to another publisher. Then if I wanted to pick it up again, I would be lower on the list.

[isoos]

I usually urge people to reach out to the owners of discontinued packages. I did it on a few occasions, and the owners usually granted me upload rights, git repo rights or both. From there on, it is up to you how you handle development going forward...

Given the recent package-name-related security attacks on another package manager, I'd be vary cautious to introduce features that could be used to confuse the consumers of a package.

[lukepighetti]

The problem is that there are a lot of people who zombify their package and don't want to let go of it who won't discontinue it either.

As far as package-name security attacks, that's a valid concern. I don't have a good answer to that right now.

[ahmednfwela]

some simple UX improvements to the website can solve any type of confusion that may arise from multiple publishers to the same package. e.g. Having the original author always at the top with an "original author" badge next to them, and being able to sort the publishers list with "recently updated". also a restriction can be made so that only verified publishers are able to fork packages on pub.dev, this should limit the number of forks to a manageable amount.

[jpnurmi]

There's a discontinued legacy package that was last published 6 years ago. The package has zero points/likes/popularity. The repository no longer exists on GitHub, either. I approached the uploader if there was any chance I could take over the package. The response was:

Your request humiliates me in my eyes.

+1 for namespacing :smile:

[ahmednfwela]

Again touching on this issue, since oauth2 might get deprecated https://github.com/dart-lang/tools/issues/375 , there is no way for community authors to create new versions of this package under the same name, which will lead to tens of packages like: oauth2_1, oauth2_2, the_best_oauth2, etc...

[Tienisto]

It would require more work for the pub.dev developers but you could create a snapshot of the current "vendors" that will become the default vendor if the pubspec.yaml specifies no vendor for a package.

This resolves the problem that ownership should stay the same.

New packages then always require a "vendor" as there will be no default vendor for new packages.

I think writing the full package name + vendor would be quite nice. E.g.

dependencies:
  dart.dev/collection: ^1.15.0

  # a little bit longer but also fine
  collection:
    version: ^1.15.0
    vendor: dart.dev

[yanshouwang]

Please add this feature as soon as possible, it's quite annoying to rename the package when publish...