{"id":13413697,"url":"https://github.com/VividCortex/johnny-deps","last_synced_at":"2025-03-14T19:33:06.238Z","repository":{"id":9607446,"uuid":"11530737","full_name":"VividCortex/johnny-deps","owner":"VividCortex","description":"Barebones dependency manager for Go.","archived":true,"fork":false,"pushed_at":"2020-12-15T17:40:08.000Z","size":79,"stargazers_count":214,"open_issues_count":3,"forks_count":7,"subscribers_count":23,"default_branch":"master","last_synced_at":"2024-07-31T20:52:38.547Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Perl","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/VividCortex.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2013-07-19T15:20:47.000Z","updated_at":"2023-06-01T00:53:15.000Z","dependencies_parsed_at":"2022-08-30T10:10:45.235Z","dependency_job_id":null,"html_url":"https://github.com/VividCortex/johnny-deps","commit_stats":null,"previous_names":[],"tags_count":10,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VividCortex%2Fjohnny-deps","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VividCortex%2Fjohnny-deps/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VividCortex%2Fjohnny-deps/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VividCortex%2Fjohnny-deps/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/VividCortex","download_url":"https://codeload.github.com/VividCortex/johnny-deps/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243635759,"owners_count":20322994,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-30T20:01:46.687Z","updated_at":"2025-03-14T19:33:05.965Z","avatar_url":"https://github.com/VividCortex.png","language":"Perl","funding_links":[],"categories":["包管理","\u003cspan id=\"包管理-package-management\"\u003e包管理 Package Management\u003c/span\u003e","Package Management","Go语言包管理","Go Compile Helpers","Relational Databases"],"sub_categories":["HTTP客户端","\u003cspan id=\"高级控制台用户界面-advanced-console-uis\"\u003e高级控制台用户界面 Advanced Console UIs\u003c/span\u003e","Advanced Console UIs","HTTP Clients","ORM","高級控制台界面","Contents","高级控制台界面","OpenGL","交流"],"readme":"# Johnny Deps ![Build Status](https://circleci.com/gh/VividCortex/johnny-deps.png?circle-token=426f85f6d52ca0b308d1f6aab01dd219afdb4cb0)\n\nJohnny Deps is a small tool from [VividCortex](https://vividcortex.com) that\nprovides minimalistic dependency versioning for Go repositories using Git. Its\nprimary purpose is to help create reproducible builds when many import paths in\nvarious repositories are required to build an application. It's based on a Perl\nscript that provides subcommands for retrieving or building a project, or\nupdating a dependencies file (called `Godeps`), listing first-level imports for\na project.\n\n## Getting started\n\nInstall Johnny Deps by cloning the project's Github repository and running the\nprovided scripts, like this:\n\n```\ngit clone https://github.com/VividCortex/johnny-deps.git\ncd johnny-deps\n./configure --prefix=/your/path\nmake install\n```\n\nThe `--prefix` option to `configure` is not mandatory; it defaults to\n`/usr/local` if not provided (but you'd have to install as root in that case).\nThe binary will end up at the `bin` subdirectory, under the prefix you choose;\nmake sure you have that location specified in your `PATH`.\n\nNote that Perl is required, although that's probably provided by your system\nalready. Also Go, Git and (if you're using makefiles) Make.\n\n## Dependencies\n\nJohnny Deps is all about project dependencies. Each project should have a file\ncalled Godeps at its root, listing the full set of first-level dependencies;\ni.e., all repositories with Go packages imported directly by this project. The\nfile may be omitted when empty and looks like this:\n\n```\ngithub.com/VividCortex/godaemon 2fdf3f9fa715a998e834f09e07a8070d9046bcfd\ngithub.com/VividCortex/log 1ffbbe58b5cf1bcfd7a80059dd339764cc1e3bff\ngithub.com/VividCortex/mysql f82b14f1073afd7cb41fc8eb52673d78f481922e\n```\n\nThe first column identifies the dependency. The second is the commit identifier\nfor the exact revision the current project depends upon. You can use any\nidentifier Git would accept to checkout, including abbreviated commits, tags and\nbranches. Note, however, that the use of branches is discouraged, cause it leads\nto non-reproducible builds as the tip of the branch moves forward.\n\n## Introducing the tool\n\n`jd` is Johnny Deps' main binary. It's a command line tool to retrieve projects\nfrom Github, check dependencies, reposition local working copies according to\neach project's settings, building and updating. It accepts subcommands much like\n`go` or `git` do:\n\n```\njd [global-options] [command] [options] [project]\n```\n\nGlobal options apply to all commands. Some allow you to change the external\ntools that are used (go, git and make) in case you don't have them in your path,\nor otherwise want to use a different version. There's also a `-v` option to\nincrease verbosity, that you can provide twice for extra effect. (Note that the\ntool runs silently by default, only displaying errors, if any.)\n\nIt's worth noting that all parameters are optional. If you don't specify a\ncommand, it will default to `build` (see \"Building\" below). If you don't specify\na project, `jd` will try to infer the project based on your current working\npath, and your setting for `GOPATH`. If you're in a subdirectory of any of the\n`GOPATH` components, and you're also in a Git working tree, `jd` would be happy\nto fill up the project for you.\n\nWhen in doubt, check `jd help`.\n\n## Retrieving projects\n\nRetrieving a Go application with Johnny Deps is just as easy as retrieving a\nsingle base project. Run `jd get` and the full application, with all transitive\ndependencies, will be set up in your environment. Here's what we'd type for one\nof our applications:\n\n```\njd get github.com/VividCortex/api-hosts\n```\n\nJohnny Deps will look for all required projects in your `GOPATH`, and download\nthose missing to the first component of `GOPATH`. It will even create the\ndirectory stated in your `GOPATH` if it doesn't yet exist. As `jd` traverses the\ngraph of dependencies, it checks whether version conflicts exist. If it happens\nto detect one, it will abort with a message like this:\n\n```\nVersion mismatch detected for github.com/VividCortex/core\n  561c9e9798307b875b8f90b89b7888eae4a983ce referenced by:\n    github.com/VividCortex/api-hosts\n    github.com/VividCortex/config\n    github.com/VividCortex/nap\n  but dfe3ff5362d778214272b56e2afcca0d96651911 referenced by github.com/VividCortex/shard\n```\n\nHere, the tool is telling you that two different versions of `core` are being\nincluded. The first is the commit identifier at the top, that is shared as a\ndependency for the three projects that follow. But `shard`, on the other hand,\nis including a different commit for `core`, shown at the last line. If no\nversion mismatch is found, you'll end up with all projects required to build the\napplication you were interested in (`api-hosts` in the example above).\n\nBesides retrieving required projects, `jd get` will reposition local copies\n(whether they existed already or were just cloned) to the version stated in\n`Godeps` files. Furthermore, if you're aiming at a specific commit (as\nrecommended), `jd` does an extra effort trying to checkout a branch whose tip\nmatches that commit, as opposed to leaving you in a detached HEAD state. That's\nmost probably what you want, cause it's probably a work in progress and you'll\nbe adding commits to that branch. (If you prefer a detached HEAD instead,\nprovide the `-d` flag to `get`.)\n\nWhen choosing a branch to checkout for a given commit identifier, `jd` will\nfirst search among all locals. If there's none whose tip matches the commit,\n`jd` will try remote tracking branches instead. Among those matching, `jd`\nselects one with a local branch by the same name, having the remote as an\nupstream branch. If there's one available, that remote branch is merged into the\nlocal, and the latter is checked out for use. Otherwise, `jd` keeps one of the\nmatching remotes with no local branch by the same name, and checks out a new\nlocal branch with that remote set as upstream. (If local branches existed for\nall candidate remotes, but none of them had the remote by the same name set as\nupstream, then `jd` would abort with an appropriate message. In that case you\nshould either review your local branches, cause there's possibly an upstream\nsetting missing, or otherwise use `-d` to checkout in detached HEAD mode.) In\nany case, if there's more than one choice and you're running with double `-v`,\nyou'd get a message displaying the other options as well.\n\nIt's worth noting that `jd` favors local operations as much as possible, to\navoid long round-trips to remote repositories. Hence, remotes won't be fetched\nif the required revision is found locally. (That's particularly relevant when\nincluding a branch name at the `Godeps` file cause, if found locally, the branch\nwill not be updated with remote changes.) Note also that, unless it actually\nneeds to move to a different release, `jd` will not insist in that your working\ncopy is clean. This is good from a developer's point of view, cause it allows\nyou to play with the application, trying modifications or fixes in the whole\ncode base, without `jd` complaining.\n\nIf the project you're interested in is not present in `GOPATH`, `jd get` will\nclone it from the remote repository and checkout the master branch. But once you\nhave a local copy, `jd` will never checkout a different revision. (It will\nchange revisions for dependencies, but not for the main project you provide to\n`jd get`.) You may reposition the working copy to your liking using Git\ncommands; `jd` will be happy to adjust dependencies accordingly. However, if you\nwant to force your main project into a specific revision, even before you have a\nlocal copy, you can use the `-r` parameter to `jd get`, like so:\n\n```\njd get github.com/VividCortex/api-hosts -r my-release\n```\n\nwhere the argument to `-r` can be anything you can checkout from Git: a commit\nidentifier (abbreviated or not), a branch or a tag.\n\nAfter working copies for all projects in the application are set, `jd get` runs\na check on first level dependencies for the main project (i.e., the one either\nyou specified on the command line, or `jd` inferred from your current\ndirectory). The check is run against the result of `go list`. `jd` will complain\nif the sets don't match exactly, displaying both missing and not required\nprojects. If that's the case, you need to fix your `Godeps` file (see \"Updating\"\nbelow).\n\n## Building\n\nSince building is what you'll be doing most of the time, `jd` conveniently\ndefaults to `build` if no command is provided. Furthermore, `jd` may be able to\nretrieve the project out of your current working directory (see \"Introducing the\ntool\" above). Hence, you'd typically be able to compile by typing only `jd` at\nthe command prompt. Not even your location within the project tree matters; the\ntool works equally fine if run from deep inside the hierarchy.\n\nBefore the actual building process, `jd` runs the equivalent of a `jd get`\ncommand. That's how it makes sure that you're actually using the correct\nversions of all dependencies. (Keep in mind, though, that if your local copies\nwere already set to the correct revisions, it's okay to have local changes; even\nin `Godeps` files.) The implicit `get` run by `build`, and the choice of `build`\nas the default command, make the tool particularly easy to use to build projects\nyou don't even have. The following command retrieves the full dependencies for\nthe application and builds:\n\n```\njd github.com/VividCortex/api-hosts\n```\n\nFurthermore, since the `-r` option to `build` is actually passed along to the\nimplicit `get`, you can readily set up a specific version by appending the\nappropriate `-r` to the command above. (The same behavior goes to the `-d`\noption to `build`.)\n\nJohnny Deps calls `go build` at the project's root to build. But, in order to\naccommodate special needs, `jd` checks for custom instructions first, resorting\nto `go build` only if there are none. The highest priority goes to the Make\nutility. If there's a file called `Makefile` or `makefile` at the project root,\nthen `make` is run. If an executable file called `build` is found, then that\nwill be invoked instead. Otherwise the tool resorts to `go build ./...`.\n\nThere's no need for a script if you need to `go install ./...` instead. Johnny\nDeps will use the later if you ask it to `install` rather than `build`. However,\nkeep in mind that this has to be explicitly asked for; `jd` defaults to `build`\nif no command is provided. The rest of the process works exactly like it does\nfor `build`, including the attempts at `make` and the `build` script. Even\nthough `jd` makes no difference between `build` and `install` when custom\nscripts are used, the command name is made available in case different actions\nare required in scripts themselves. This is published as the `JD_ACTION`\nenvironment variable.\n\n## Updating dependencies\n\nJohnny Deps can't decide which releases to use from the project's you import.\nBut it can help writing the `Godeps` file. By running `jd update`, `jd` will\ndisregard the current dependencies in the `Godeps` file, overwriting it with the\nlatest master release for each project you depend upon, after pulling. Of\ncourse, that may or may not work. Using the latest release for each dependency\ncould potentially lead to inconsistencies (version mismatches), that would make\n`jd` complain. The dependencies file would have been changed anyway. It's your\nresponsibility to decide which projects to upgrade or withhold.\n\nIt's worth noting that `jd update` does not rely on the `Godeps` file to check\ncurrent dependencies; it takes them from `go list` instead. A nice consequence\nis that new imports are automatically detected from the code and added to\n`Godeps` with no manual intervention required. (And no longer needed imports\nwill be removed as well.) Note also that, although the old dependencies file is\noverwritten, the new copy is not committed or even staged for commit in Git.\n(Rationale: you should test that everything still works properly!) You can do\nthat with the rest of your changes, without leaving traces in history if you run\nthe update multiple times before you're done.\n\n## Return codes\n\nThese are the return codes for `jd`:\n\n* 0 - Success\n* 1 - Error with parameters\n* 2 - Bad dependencies or unable to read them\n* 3 - Version mismatch detected\n* 4 - External command failed\n* 5 - Unable to checkout requested revision\n\n## Workflows\n\nJohnny Deps is intentionally agnostic about the specific workflow used. In\npractice, people seem to fall into one of two camps that reflect how they think\nabout dependency management, and their differing goals.\n\nThe first category, roughly speaking, is those who would like to build from the\ntip of their source control repositories all the time, but have a need for\npinning some things to a specific version. Those users may use branch names in\n`Godeps` as opposed to commit identifiers, and change to a specific commit when\nthey need to pin a version. (Nevertheless, `jd` will not automatically fetch the\nlatest changes. See \"Retrieving projects\".)\n\nThe second school of thought holds that the `Godeps` file should contain\nexternal dependencies and their exact versions, so that checking out a\nparticular revision of an application's repository and running `jd` will result\nin exactly the same versions of all of the code used to build the application,\nevery time.\n\nAt VividCortex, we want to be able to reproduce a binary for debugging or other\npurposes. All of our builds have a command-line flag called `--build-version`\nthat, when present, will result in the binary printing out the Git revision from\nwhich it was built. We can thus easily reproduce any version by calling `jd\nbuild` with that revision as the `-r` parameter. To embed the revision in the\nbinary, we use a specific shell script called `build` (see \"Building\" above)\nthat runs something like:\n\n```\ngo build -ldflags \"-X main.Godeps '$(git rev-parse HEAD)'\"\n```\n\nAt the application we set things up so that `--build-version` displays the\ncontents of the `main.Godeps` variable set by the compiler.\n\n## Contributing\n\nWe welcome issue reports, suggestions, and especially pull requests:\n\n1. Fork the project\n2. Write your code in a feature branch\n3. Add tests (if applicable)\n4. Run tests (always!)\n5. Commit, push and send Pull Request\n\nBecause this is a VividCortex internal tool that we're sharing publicly, we\nmay not want to implement some features or fixes.\n\n### TODO\n\nAdd tests. Those we previously had are not appropriate for the new tool.\n\nOptionally add support for other repositories, like Mercurial. This tool is now\ntargeted at Git on github.com, that is what we use at VividCortex.\n\n## License\n\nCopyright (c) 2013 VividCortex.\nReleased under the MIT License. Read the LICENSE file for details.\n\n## Contributors\n\nJohnny Deps is the combination of several different thought processes from\nmultiple authors, with inspiration from tools such as Ruby's Bundler and dep\ngem, Python's pip, and others. Give credit to [@xaprb](https://github.com/xaprb)\nand [@gkristic](https://github.com/gkristic).\n\n![Johnny Deps](http://i.imgur.com/MuupBVC.jpg)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FVividCortex%2Fjohnny-deps","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FVividCortex%2Fjohnny-deps","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FVividCortex%2Fjohnny-deps/lists"}