launchpad.net/gocheck => gopkg.in/check.v1

[Gustavo Niemeyer]

The gocheck project has moved to GitHub, and adopted a versioned API.
The API is still 100% compatible, though.

What changed was:

- Import path: gopkg.in/check.v1 [1]
- Package name: check rather than gocheck
- API documentation: https://gopkg.in/check.v1 [2]
- Command line flags: -check.* rather than -gocheck.* [3]

[1] Old still works for the time being, to keep things running
[2] Also brought in line with Go style
[3] Old -gocheck.* still works for the time being, to avoid breaking scripts


gustavo @ http://niemeyer.net

[Gustavo Niemeyer]

Ah, and the project page with high-level docs is still at:

http://labix.org/gocheck

--

gustavo @ http://niemeyer.net

[Dave Cheney]

I don't like the import path "gopkg.in/check.v1" at all. I didn't even know that you could have periods in a packages' name, and now I realise it is possible, I wish it were not. 

import "gopkg.in/check.v1" // valid syntax, but check.v1 is not usable

import something "gopkg.in/check.v1" // I have to make up a new name at file scope

So now I can't even use that import without picking a new name for it. This is a disaster.

What was wrong with the gopkg.in/vNNN/check semantics ?

Please reconsider this.

Dave

[Wes Freeman]

It takes the package name instead of the .v1 part when you're using it in the program. check.v1 becomes check, for example. 

Wes

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gustavo Niemeyer]

The package name is "check", and you can use it with:

import "gopkg.in/check.v1"

Please see these threads for details on the choice:

http://goo.gl/4nfVlM
http://goo.gl/WA95Sz

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Dave Cheney]

I'm sorry, I think this is wrong. Very wrong. I'm appalled at this. I
don't want anything to do with this 'solution'.

[Wes Freeman]

I am missing something, though... I just realized that the godocs for the gopkg.in redirected repositories don't show links to any source files. :( 

For example, I'm having a lot of trouble finding your new gocheck repository in github.

Wes

[Gustavo Niemeyer]

Yeah, this is the case for all custom URLs at the moment. Already in
conversation with Andrew to get that sorted, though.

[Gustavo Niemeyer]

Surprisingly harsh coming from you, Dave. We've held an open
conversation about options, and also private with current users of
gopkg.in, and three Go core developers. Most people I talked to
appreciated the change, and I like it too. Also worth noticing that
I'm not even being original (see google-api-go-client, for example).

So, not only it's not wrong, but it's also a pretty good pattern given
the options.

[Wes Freeman]

I like it. It's easy to tell that it's a version because it's out of place, compared to the path that looks like it might be a subpackage.

Once you realize the package name isn't affected by the .vX it's pretty simple to use.

Wes

[Aram Hăvărneanu]

This foo.vn business is terrible, I will never use a package with such
an ugly name.

--
Aram Hăvărneanu

[James Bardin]

Does no one understand that the import path and package name are not the same thing?

[chris dollin]

On 1 April 2014 12:47, James Bardin <j.ba...@gmail.com> wrote:

Does no one understand that the import path and package name are not the same thing?

Many people understand this, but at least some of them would very

much prefer keeping to the well-established convention whereby the

last fragment of the import path is the same as the package name.

Since Go package names can't contain dots or dashes, a final

fragment like v1829-spoo or v1829.spoo could claim to match that

convention, and fragments like spoo.v1066 just about so by saying

the package name is the bit before that dot (or dash) if there is one.

But Unhappies.

Chris

--
Chris "1 1 2 3 5 8 13 unhappies" Dollin

[Gustavo Niemeyer]

The convention foo.v1 clearly associates the version with the right
portion of the URL, makes it clear what is the API version being
imported, organizes the local filesystem in a sane way, keeps the
package name as a relevant part of the suffix, and as Roger pointed
out, it has the great advantage of being easily implementable without
a convenience service.

It's also clear that nothing we could do would have everyone entirely
happy. The option selected is just the one that most people were
comfortable with, and that had the most visible advantages.

I'm now moving on to adopt it, bringing stable API versions for
additional packages.

[Ernest Micklei]

[off topic]

 

How about a badge or icon that developers can stick on their Readme page to show that the project supports gopkg.in ?

[Gustavo Niemeyer]

I suggest just a trivial section in the markdown that points out the
import path.

For example:

https://github.com/go-check/check/blob/v1/README.md

[Fatih Arslan]

I just wanted to add gopkg.in for the set package. I thought it was
still like gopkg.in/github.com/v1/foo, which I see is not anymore. I
know that was talked before, but is there a way we could also support
this way of declaring a import path?

Fatih Arslan

[Gustavo Niemeyer]

Hi Fatih,

On Wed, Apr 2, 2014 at 11:39 AM, Fatih Arslan <ftha...@gmail.com> wrote:
> I just wanted to add gopkg.in for the set package. I thought it was
> still like gopkg.in/github.com/v1/foo, which I see is not anymore. I
> know that was talked before, but is there a way we could also support
> this way of declaring a import path?

That URL was never supported. Nevertheless, it seems best for us to
support a single style over time, so people importing packages can
tell what to expect rather than always pondering what's the style that
one package is using. This will also make the pattern stronger, and
make it feel natural.


gustavo @ http://niemeyer.net

[Nate Finch]

On Tuesday, April 1, 2014 10:08:37 AM UTC-4, Gustavo Niemeyer wrote:

it has the great advantage of being easily implementable without
a convenience service.

Before I read the above, I was still on the fence about this change.  Although I really like the convention of keeping the last part of the path the same as the package name, I think the point above overrides that fact.  This is a versioning scheme that anyone can implement without third party help.  That's incredibly important.  With this scheme, the only benefit to gopkg.in is that you can make the versions branches on the same repo, rather than requiring a different repo for each version.  With the prior /v2/name scheme, it was impossible to implement without a redirector, unless you put all your v2 packages in the same repo (which I think we can all agree is a non-starter).  With the name.v2 scheme, it means that people that want to maintain their code without use of a redirector service can do so trivially, and still support a standard versioning scheme.  This will make versioning of packages more attractive, which can only be good for the community.

People will get used to the package name being just the last section minus the version.  If it becomes a convention, it'll only be something that confuses newbies, like how x := range foo has x being the indices, not the values.

If someone has a better solution, I am all ears.