Re: [dh-make-golang][Solution]

Hello Utkarsh,

Here are the comments on your inspection report.

The reason you are getting three different results is intentional. Graph and Tree will print all the dependencies with respective structure, while the list will only print the 1st level dependencies.
While creating this tool I use the same checking convention as used by dh-make-golang, so both GoCheckDeb and dh-make-golang are using https://api.ftp-master.debian.org/binary/by_metadata/Go-Import-Path to check if a dependency is packaged. I think you can cross-check with the team about which method we should be using, if it's a different one, I will be happy to implement it. :)
As I mentioned earlier, eventually this tool will be a part of dh-make-golang estimate command, since I also created a package for it, and the tool is just to test it out.
As I explained to you in the telegram app, that this tool or no tool can work on a project/folder which does not have the golang files in the mentioned path. So, if you go to https://github.com/zyedidia/micro, it doesn't contain a single golang file, rather you should use the tool on following path https://github.com/zyedidia/micro/cmd/micro, which directs to a directory which actually contains the source code in golang files, checks it on GitHub here: https://github.com/zyedidia/micro/tree/master/cmd/micro/.
we do need to check with full depth, to understand why, let me quote the issue(https://github.com/Debian/dh-make-golang/issues/89)
" While running,dh-make-golang <package-name> we get a list of dependencies which are still not in Debian.
Then we have to do the same thing for all the dependencies and their sub-dependencies on multiple hierarchies manually."
The reason we need to check sub-dependencies is that golang is compiled , so all the packages needs to be downloaded while compiling and if there is even a sub-package of a sub-package which is not yet in Debian, we can not compile the original package we intended to get on Debian.

I hope I was able to clear all the raised doubts but is there is anything I missed, please feel free to reach out to me here or any other platform. :)

Regards

Raman Tehlan
Engineer | Developer | Designer

https://ramantehlan.github.io

On Fri, Jul 5, 2019 at 4:53 AM Utkarsh Gupta <guptautkarsh2102@gmail.com> wrote:

Hey,

[Removing d-devel]

On 13/05/19 12:10 am, Raman Tehlan wrote:

Hello,

I have created both a library and a tool to get a recursive list of all the golang dependencies which are or are not yet packaged in Debian, I am addressing this [issue](https://github.com/Debian/dh-make-golang/issues/89), for which I create my solution [here](https://github.com/ramantehlan/GoCheckDeb).

Once I have the feedback from the community, I will make the pull request to implement it in the official project [here](https://github.com/Debian/dh-make-golang)

I got the time to look at it and explore the features it has and came across a couple of things, which are as follows:

I tried looking up the dependencies of lazygit via all the options available and got different results.
   a. via graph: https://paste.debian.net/1090346/
   b. via map: https://paste.debian.net/1090345/
   c. via list: https://paste.debian.net/1090347/

Also, it shows "(No Deb Package)" for packages that are actually packaged and are available on tracker.debian.org. I am not sure if I am missing something, am I?
On the other hand, it should actually reflect the output of dh-make-golang's estimate command.
That appears to work perfectly for me, like the --recursive way Raju mentioned on that issue.

Another thing I noticed is that for various projects, for instance, micro, it throws an error: https://paste.debian.net/1090348/ :(

Here's a quick inspection (Jongmin Kim did):
I think the main problem is GoCheckDeb tries import path with full depth (even sub-directories).
It should check if lazygit is packaged or not, but not lazygit/pkg/config, lazygit/pkg/utils, lazygit/vendor/..
Same for golang.org/x/text. While it should check if it is packaged or not, it also checks for golang.org/x/text/language, which I think is not necessary, or is it?

I am not sure if I am missing something that is obvious? Or the above reports are correct.
Please let me know what you think :)

Best,
Utkarsh