[pubspec] Allow explicitly pub.dev for publish_to

[AlexV525]

This is a feature request and we previously have discussions with @jonasfj at dart-lang/sdk#47815 (comment). TL;DR, pubspec.yaml can allow the publish_to field to be set to https://pub.dev or https://pub.dartlang.org even if it's omitted.

Consider the case when some of the packages are mainly maintained by developers who used to have another PUB_HOSTED_URL (like us, using https://pub.flutter-io.cn) in their environments. To publish the package to pub.dev, we have a couple of ways to accomplish it:

Set PUB_HOSTED_URL temporarily to "" or "https://pub.dev" in the current terminal session
: Manually doing this is frustrating for every publish but it's working.

Write shell scripts to set PUB_HOSTED_URL in their running env
: As the previous comment suggested, this is a more advanced way, but we still need to write .sh, .bat that run on different platforms.

Use CI/CD (e.g. GitHub Actions) to follow the specific publish steps
: Now we are automated! All steps are gathered and we only need to write the environment or prepare steps once. But the preparation is actually transferred from the user end to the integration end. It has less possibility to be changed frequently.

Why not use Docker?
: Sure, but let's look back to the integration path, we've already done too many for the publish.

So IMO, when we treat https://pub.dev as the default and the omitted value, we'll need to think from the reverse perspective. When the omitted value (as the developer aspect) is not https://pub.dev, the most solid way might be the fixed value of publish_to in the pubspec.yaml, and follow the condition publish_to -> PUB_HOSTED_URL -> https://pub.dev. It can be the minimal cost when we want to publish packages to pub.dev forever when we have various environments.

[sigurdm]

We discussed this, and think that our work on publishing from github will make this less interesting.

Closing as wontfix.

[AlexV525]

We discussed this, and think that our work on publishing from github will make this less interesting.

@sigurdm Does that mean the general publish support for GitHub? What about other service providers like GitLab or some localized git providers. Could you provide more thoughts and opinions about why this will be less interesting? I didn't see any information in that issue.

[sigurdm]

In general we will encourage publishing from github (and yes - we also plan support for gitlab). Then this mistake cannot happen, and therefore the issue becomes less important.

We don't want a publish_to line on pub.dev because we already changed the url once, and it would just clog up the pubspecs of published packages.

What we really should do to avoid this issue is a proper mirror-support (so that the usage of a mirror is transparent) instead of the kludge that is a globally set PUB_HOSTED_URL. We do have some ideas in this space - but nothing on our current roadmap.

[AlexV525]

it would just clog up the pubspecs of published packages.

This is make much more sense to me. Thanks for pointing this out.

What we really should do to avoid this issue is a proper mirror-support (so that the usage of a mirror is transparent) instead of the kludge that is a globally set PUB_HOSTED_URL.

As the mirror maintainer, we've also tried to publish packages transparently using the mirror by setup some redirections (301, 302) for /api/packages/versions/new (APIs after authentication), but the auth HTTP client will handle those redirections automatically, which makes the token become a required field for each mirror. It's working before multiple server token support. Please let us know if anything we can improve when dealing with requests like this. 💙

[jonasfj]

As the mirror maintainer, we've also tried to publish packages transparently using the mirror by setup some redirections (301, 302)

I would suggest not publishing through a mirror. Authentication tokens for pub.dev should never be sent a another party, that would be a security vulnerability.

In an ideal world the pub.dev repository would have signatures inspired by something like the-update-framework, if we had that, then it would be reasonable for the dart pub client to pretend that the mirror is indeed pub.dev. And there would be no need to modify publish_to. It would probably have to be enabled using a different environment to set or a global config file. If we had proper support for mirroring we could probably also write pub.dartlang.org in the pubspec.lock instead of writing the mirror URL. But this is a non-trivial change -- we've already started on parts of it (content-hashing).

[AlexV525]

I would suggest publishing through a mirror. Authentication tokens for pub.dev should never be sent a another party, that would be a security vulnerability.

Currently, it seems unimplementable because we can't forward authentications from the mirror, along with some other security reasons.

If we had proper support for mirroring we could probably also write pub.dartlang.org in the pubspec.lock instead of writing the mirror URL. But this is a non-trivial change -- we've already started on parts of it (content-hashing).

It's great to have your support! Please let us know any relevant ideas and progress and mention us (me or @chenglu) if you're able to do so. Thanks!

[jonasfj]

Currently, it seems unimplementable because we can't forward authentications from the mirror, along with some other security reasons.

Sorry, I missed a "not". Let me correct that:

I would suggest not publishing through a mirror. Authentication tokens for pub.dev should never be sent a another party, that would be a security vulnerability.

[jonasfj]

@AlexV525 I have @chenglu "bookmarked" as point of contact for the Chinese community mirror :D

If you're also a maintainer for it, please have him drop me an email CC'ing you.. I just have a note to myself about who to ping if there is issues with the Chinese community mirror.

It would certainly be nice to improve some of the issues people using the mirror runs into...
But I think publishing from github actions is a good start :D

[chenglu]

Alex actually reach me out more often than Jonas for the community mirror ;-) As he is deeply involved in the organization @fluttercandies, which open-sourced over 80+ helpful Flutter packages, and Alex often serves as a representative in giving feedback that the mirror is not up to date with the packages developed by them.

So any questions from the CN Flutter devs or package devs about the CN community mirror, feel free to reach me or Alex out, or file an issue to us here; Any pub.dev related changes that need to be supported and tested on the CN mirror, continually "bookmark" Luke ;-) Thanks!