I want to migrate one project already done to Poetry but couldn't find the equivalent to "pipreqs /path/to/project/"
So i have to run pipreqs then "poetry add" manually
Related
In a life cycle of a php project we have
install: composer install
publish: composer push
But, what would be the command to build a php project with composer?
what would be the command to build a php project with composer?
Simply speaking, you build the PHP project. Composer is a utility you can use to manage a PHP projects dependencies. Additionally you can also use it to define your PHP project.
How you build the PHP project is entirely up to you. This is normally dependent of what kind of PHP project that is and how you organize it.
To give an example: Lets consider your PHP project just is the project directory with the composer.json at its root with all the other sub-directories and files.
Composer operates within that directory. So when you want to create a build artifact of that project you do the following:
composer install --no-dev - Prepare the vendor folder with the production dependencies and the autoloader.
composer archive - Create the build artifact.
As you will do this quite often and over and over again you could add a Composer Script named build or similar to put things together:
{
"scripts": {
"build": [
"#composer --no-plugins --no-interaction install --no-scripts --no-dev",
"#composer --no-plugins --no-interaction archive"
]
},
"scripts-descriptions": {
"build": "Build project artifact."
}
}
You can then run:
$ composer build
...
Composer will then output the file-name. By default it should be a .tar file (tarfile, tarball), you can inspect it on the commandline with the tar utility (here gnutar):
$ tar -tvf "$(composer show -sN | sed 's|/|-|')"*.tar | less
And that would be the example. Whatever composer push is, I don't know. It is likely that you have it somewhere in your Composer configuration. So I can't comment on it.
To extend a bit on the given example: I manage most (if not even all) of my PHP projects with Composer. However this is not the full truth. I actually version control them with Git. Looking from a birds perspective, the Git utility is way more leading than the Composer utility. That is for example, that I want to be able to build a specific git revision.
Now Composer is not that bad with Git. It recognizes if the project exists and in case of the composer archive example, it even puts the git revision hash into the file name of the build artifact.
However Composer operates in-tree. That is the place where the development happens as well, so this can easily clash (you don't want the build to remove the development dependencies while you're running tests as well - or afterwards). And even Composer recognizes that the project is managed by Git, it is otherwise a bit dumb as Composer is merely concerned about the dependencies and knows very little about the project itself - it can't just guess how you manage the overall project.
So what then commonly happens is that you still use Composer during the build but you have a dedicated build process and runner that knows the ins and outs of the project and its build.
$ make
is such a runner. Works with a Makefile in the project, e.g.
$ make deploy
knows when it needs to build again. And speaking of PHP projects: It certainly can just rsync to remotes and run smoke-tests to mark the deployment as green (use old, dumb tech and keep it simple).
I am working on two projects, let's call them Project A and Project B.
Project B requires some modules in Project A, so I did a poetry build on Project A. I am able to access the module when I manually perform a pip install dist/blabla.whl on the build produced by poetry on Project A.
But when I do a poetry add project-a git+ssh://git#gitlab.blabla.co/nubela/project-a.git#develop, it says
Could not find a matching version of package project-a
Naturally, I understand because project-a is not classically packaged with setup.py and stuff. How can I then perform a poetry add <git-repo-uri> without involving self-hosted pypi instance?
I can push the .whl files to the project git repo, does that help?
The correct syntax would be
poetry add git+ssh://git#gitlab.blabla.co/nubela/project-a.git#develop
More examples are in the docs
I can push the .whl files to the project git repo, does that help?
While it would theoretically solve the issue, treating a repository as a file server sets you up for headaches - if your gitlab even allows uploading binaries in the first place.
Given the error message you're getting, it doesn't seem to be a poetry or setuptools issue, it is git that is complaining. Did you make sure that you have a tag or branch on your repo that is called develop? While it is not explicitly mentioned, the form of poetry add in the git-mode is
poetry add git+<protocol>://git#<repository>/<owner>/<project>.git#<git_ref>
The final #<git-ref> is optional, and if omitted poetry will install whatever is currently on the default branch (most likely "master"). What you probably want is just
poetry add git+ssh://git#gitlab.blabla.co/nubela/project-a.git
When using govendor, what is the difference between go install, govendor install +local and govendor install +vendor,^program?
govendor install +vendor,^program says to build and install all my vendor packages. but what and where will it install to? Will it install my project and vendor's command executables to $GOPATH/bin and my project and vendor's package objects to $GOPATH/pkg?
govendor install +local says to build everything in your repository only. So what does it really mean? Will it create vendor/bin and vendor/pkg?
what about if I run go install in my project? What will this be different to the above two commands?
Go first came into the world with a brand new idea for dependency management and workspace folder structure. There was a strict hierarchy where projects would be located (in $gopath/src/site.com/user/project) and other projects would simply import the latest version of all other projects. The problem with this is that if some upstream project changes the API, then your project will break inexplicably. This is where vendor comes in.
Vendor is a subdirectory in your project that contains everything under $gopath/src that your project imports. The difference is that vendor isn't updated when upstream projects introduce new features and/or fixes. Therefore, you must update it yourself. When go looks for an import (as of the latest version), it will check vendor first and then look for the latest version in your $gopath, preventing builds from inexplicably breaking for no apparent reason.
go install updates your $gopath dependencies to the latest version; the version that all new projects and those without vendor will use.
govendor install +vendor,^program updates your specific project vendor dependencies. This should be done in a separate commit; you should go test; govendor; git commit; go test so that you can check whether updates break your project.
govendor install +local apparently just builds the project.
Also, you should IMHO use godep rather than govendor. It IHMO has better workflow; your $gopath has the latest versions and then you can update your project with godep update. It is also supposed to be standard in golang 1.10.
I have used godep and vendored all my dependencies in vendor/ directory. Go build is working fine as well. However how can I be sure that all my dependencies are vendored?
Is there any command that can make sure of that?
My CI service (Travis is the one I use) lets me know. Because my test build will fail if the deps aren't available.
You should be using a CI service anyway, and then you get that benefit for free.
I use govendor to manage the dependencies, which has a status option. Here's some of the commands with govendor:
init Create the "vendor" folder and the "vendor.json" file.
list List and filter existing dependencies and packages.
add Add packages from $GOPATH.
update Update packages from $GOPATH.
remove Remove packages from the vendor folder.
status Lists any packages missing, out-of-date, or modified locally.
fetch Add new or update vendor folder packages from remote repository.
sync Pull packages into vendor folder from remote repository with revisions
from vendor.json file.
migrate Move packages from a legacy tool to the vendor folder with metadata.
Specifically, you'd do govendor status to check if there are missing packages.
If you decide to use govendor, you can get started by doing:
go get github.com/kardianos/govendor
govendor migrate (which will migrate from godeps to govendor)
Also, you mentioned in a comment that your deploying to Heroky, here's some documentation from them on govendor
I keep running into the issue where I install dependencies locally, it works fine, I push to continuous integration server, and then it breaks because I forgot to godep save ./... the dependency.
How can I run the go command but require vendor imports?
Edit:
I'm using go1.6. I want the command to fail if a 3rd-party dependency does not resolve to vendor. In other words, is there a way to stop resolving dependencies in $GOPATH during tests?
I can't change the environment variable because then none of my project modules can be resolved. How can I force vendor dependencies?
There is no way to prevent builder to scan $GOPATH for packages. It seems, that you use not really good flow for manage dependencies. I recommend you to use glide for a vendoring.
Most recommended workflow:
Keep actual list of dependencies in glide.yaml.
Run glide up after any changes in glide.yaml. It will install all dependencies to vendor directory and generate glide.lock with fixed package versions. Commit glide.lock to VCS. Do not change manually glide.lock.
Do not commit vendor directory to VCS.
Run glide install on your CI or build server to install dependencies by glide.lock to vendor.
Build.
A migration from godep to glide may be done easily, because glide has a command to migrate Godeps.json to glide.yaml.