Ply still imports "howett.net/plist"

[satta]

The ply subdirectory still imports "howett.net/plist" while there is a GitHub repo URL for it.
This keeps the problem mentioned in #16 around, which is currently a dealbreaker when using helper tools like dh-make-golang (https://people.debian.org/~stapelberg/2015/07/27/dh-make-golang.html).

Please import the GitHub repo for plist in ply.

[DHowett]

Since howett.net no longer serves an invalid cert, this should not be an issue. The canonical import path will remain howett.net/plist (and I'll light up howett.net/plist/ply)

[DHowett]

The import path howett.net/plist/ply is lit up. The meta tags redirect them both here.

[varac]

@DHowett Can you explain your reasoning why you don't want to include the github repo URL instead of howett.net ?

It's considered as an unknown hoster to dh-make-golang:

--- /tmp » dh-make-golang github.com/coyim/coyim                                                                                                                                                               1 ↵
2017/10/17 10:03:42 Downloading "github.com/coyim/coyim/..."
2017/10/17 10:03:52 Determining upstream version number
2017/10/17 10:03:52 Package version is "0.3.8+git20171017.235.25498a6"
2017/10/17 10:03:52 Determining package type
2017/10/17 10:03:52 Assuming you are packaging a program (because "github.com/coyim/coyim" defines a main package), use -type to override
2017/10/17 10:03:52 Determining dependencies
2017/10/17 10:03:54 Cannot derive Debian package name: unknown hoster "howett.net". See -help output for -allow_unknown_hoster

While this still can get worked around easily by allowing unknown hoster with the -allow_unknown_hoster flag, it would be much easier to use the already existing github URL.

[varac]

Packaging gets even harder because dh-make-golang is not recognizing any packaged version of plist:

…
The following packages have unmet dependencies:
 pbuilder-satisfydepends-dummy : Depends: golang-howett-plist-dev which is a virtual package and is not provided by any available package

With the github URL, it would have recognized that there's already a debian package called golang-github-dhowett-go-plist-dev.

So if you want to make debian packaging easier for all projects that build-depends on plist, pls consider using the github URL.

[DHowett]

Hi @varac. Sure, I'll get into the rationale a little bit.

I place a high (though perhaps unreasonably so!) value on being able to control certain parts of my own infrastructure. That includes not taking a sole dependency on any particular provider. I very much appreciate GitHub as a service, and I absolutely want to be properly packageable on Debian, but I think of my projects as foremost namespaced under a root I own, not by the open-source hosting provider I choose to use. Now, of course, I do realize that blind ideology is the enemy of lots of things.

It looks like:

• There's precedent for dh-make-golang to include a personal domain in the set of known hosts (here)
• Adding howett.net there would resolve most, if not all, of these issues.

I've chatted with @satta out of band about packaging for this project, but not about this in particular. Sascha, I'd be interested to hear your thoughts!

Reopening this, as well, since it's clearly an issue.

---

Curiously, it looks like coyim specifically is vendoring plist through the github.com import path, and it doesn't seem to import anything that imports howett.net/plist even transitively.

[dmitshur]

So if you want to make debian packaging easier for all projects that build-depends on plist, pls consider using the github URL.

To play devil's advocate, what if dh-make-golang didn't have good support for Go packages on github, should he move plist to a different code host then?

I think a better solution would be to improve dh-make-golang to have better support for vanity import paths.

[DHowett]

@shurcooL I completely agree. I'm at a loss (as is the dh-make-golang maintainer) for what Debian could do better in this regard. Right now, if you pass -allow... it strips off the known public suffix and embeds everything else in the package name. Since that's hidden behind a flag, it's not really accessible.

Maybe that's a good generic solution?

As a mitigation, dh-make-golang will as of Debian/dh-make-golang#71 recognize howett.net as a valid import path. I may move to make this package express that as its canonical import path.

@varac Once the new helper hits the distribution suite you're using, is this an acceptable resolution?

[dmitshur]

@DHowett This is a small issue, but it would probably help to update cmd/ply/README.md#installation to say howett.net/plist/cmd/ply instead of github.com/DHowett/go-plist/ply (which doesn't even exist anymore, since the command was moved in cmd subdirectory).

[varac]

@DHowett Sure, that's fine. Thanks alot for fixing this !

[DHowett]

@shurcooL: thanks for the catch.
@varac: excellent. I'll close this out then.