gin-swagger icon indicating copy to clipboard operation
gin-swagger copied to clipboard

swag cannot generate docs when main go is located in directory

Open kotyara85 opened this issue 5 years ago • 12 comments

My project structure: ./ ./cmd/main/main.go ./internal/xxxx ./pkg/xxxx

When I run swag init under root directory of the project it complains on absence of main.go. When I run swag init under cmd/main/main.go it doesn't include ./internal or ./pkg directories

kotyara85 avatar Aug 08 '19 17:08 kotyara85

You can target swag cli to files that you need. For example:

swag init -g ./cmd/main/main.go -o ./docs

it will execute swag on your main.go file and put docs it root dir. For more information you could check swag repo https://github.com/swaggo/swag

And what do you mean by "doesn't include ./internal ..."

0xk175un3 avatar Aug 22 '19 12:08 0xk175un3

very helpful~~

game1991 avatar Jun 17 '20 07:06 game1991

Yeah this still doesnt work for me as there is still the error when using the above parameters:

warning: failed to get package name in dir: ./, error: execute go list command, exit status 1, stdout:, stderr:can't load package: package .: no Go files in /home/xxxxxxxx

Mentioum avatar Nov 23 '20 11:11 Mentioum

So I worked around it by doing the following:

My file tree looks something like this.

./
./cmd/server/main.go
./pkg/rest/
./pkg/otherservice
./pkg/anotherservice

I run the following command in the project root directory:

swag init -g ../../cmd/server/main.go -o ./pkg/docs -d ./pkg/rest

So there are few things to note here which I thought were really weird.

1.) As you can see the -g parameter uses the -d parameter as its starting directory, whereas -o does not and instead used the current working directory as its starting directory. This is weird and inconsistent. I feel they should either both be relative to the -d parameter directory or both be relative to the cwd. 2.) I can get what I want as all the functions i need are in my rest package. Perhaps it would be good if you could allow for some directory walking instead of assuming everything will be in one directory when loading definitions, or at least allow a way to include several directories when looking for definitions? (Ideally you'd do what go-swagger does and walk your dependency tree from main.go) EDIT: dependency tree walking can be done using --parseDependency

If you feel these should be separate issue please let me know and I will make them.

Mentioum avatar Nov 23 '20 12:11 Mentioum

Interestingly there is a way to do what go-swagger does - aka dependency hunting. Using the same structure as above I can run the following command instead:

swag init -d ./cmd/server -o ./pkg/docs --parseDependency

Takes a while (slower than go-swagger for whatever reason) but at least it generates everything I'd like.

I really think the base readme should try to make the options for swag init clearer. Also the issue with -d and the relative paths still stands as in my previous comment.

Mentioum avatar Nov 23 '20 12:11 Mentioum

I have my gin code running in a subfolder of my Go project, it doesn't recognise it as well. Anyone an idea?

 swag init

cedricve avatar Dec 28 '20 20:12 cedricve

I am having the same issue. My repository structure is same as @kotyara85 and the moment I move my controllers out of main.go file to pkg directory the auto generated swagger docs fails to pickup the route. Did anyone find a solution?

fuddin95 avatar Dec 09 '23 22:12 fuddin95

--dir value, -d value                      Directories you want to parse,comma separated and general-info file must be in the first one (default: "./")

Above is from the output of swag init --help.

My project structure is as follows:

├── LICENSE
├── Makefile
├── README.md
├── cmd
│   └── server
│       └── main.go
├── deployments
│   ├── docker-compose.yml
│   └── prod.Dockerfile
├── docs
│   ├── docs.go
│   ├── swagger.json
│   └── swagger.yaml
├── go.mod
├── go.sum
├── internal
│   ├── router
│   │   ├── registry.go
│   │   └── router.go
... ...
├── pkg
... ...
└── testdata

And I met the same error with swag init.

Using swag init -d ./cmd/server,./ worked perfectly fine.

crazyoptimist avatar Jan 27 '24 04:01 crazyoptimist