Create constants visible across packages, accessible directly

I would like to define my Error Codes in a package models.

error.go

package models

const{
  EOK = iota
  EFAILED
}

How can I use them in another package without referring to them as models.EOK. I would like to use directly as EOK, since these codes would be common across all packages.

Is it the right way to do it? Any better alternatives?

To answer you core question

You can use the dot import syntax to import the exported symbols from another package directly into your package's namespace (godoc):

import . "models"

This way you could directly refer to the EOK constant without prefixing it with models.

However I'd strongly advice against doing so, as it generates rather unreadable code. see below

General/style advice

1. Don't use unprefixed export path like models. This is considered bad style as it will easily globber. Even for small projects, that are used only internally, use something like myname/models. see goblog
2. Regarding your question about error generation, there are functions for generating error values, e.g. errors.New (godoc) and fmt.Errorf (godoc).
   For a general introduction on go and error handling see goblog

W.r.t. the initial question, use a compact package name, for example err.

Choosing an approach to propagating errors, and generating error messages depends on the scale and complexity of the application. The error style you show, using an int, and then a function to decode it, is quite C-ish.

That style was partly caused by:

• the lack of multiple value returns (unlike Go),
• the need to use a simple type (to be easily propagated), and
• that gets translated to text with a function (unlike Go's error interface), so that the local language strings can be changed.

For small apps with simple errors strings. I put the packages' error strings at the head of a package file, and just return them, maybe using errors.New(...), or fmt.Errorf if the string needs to be completed using some data.

That 'int' style of error reporting doesn't offer something as flexible as Go's error interface. The error interface lets us build information-rich error structures, to return useful information, and not just an int value or string.

An implication is different packages can yield different real-types which implement the Error interface. We don't need to agree a single error real-type across an entire set of packages. So error is an interface which can be easily propagated, like an int, yet, the real-type of error can be much richer than an int. Error generation (implementing Error) can be as centralised or distributed as we need, unlike strerror()-style functions which can be awkward to extend.