Hello Utkarsh, Here are the comments on your inspection report.
1. 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. 2. 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. :) 3. 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. 4. 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 <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/. 5. 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 <[email protected]> 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 > >
