Used in the project Slim + Slim/Extras + Twig.
I need to use it https://github.com/codeguy/Slim-Extras/pull/87 ,
but at the moment pull-request not accepted.
How do I properly configure the Composer?
So far, so as not to inhibit the development, fix the code in folder vendor, but this is absolutely the wrong approach.
If I understand this correctly, you need to add your own repository.
There might be problem in the same name of branch (origin: master, yours: master). Try changing your branch name if this happens.
"require": {
"slim/extras": "master"
},
"repositories": [
{ "type": "git", "url": "https://github.com/mvader/Slim-Extras.git" }
]
Related
I am developing a package for a Laravel project on my local machine. I have also spun up a Laravel app so I can manually test the package. My package is located at /home/me/packages/me/my-package and a commit (git) has been tagged with '0.1'.
I want to be able to switch between tagged versions and use specific versions in different projects but having issues.
In my main apps composer file, I am requiring the package like so:
...
"require" : {
"me/my-package" : "0.1"
}
...
"repositories" : [
{
"type": "path",
"url": "/home/me/packages/me/my-package"
}
]
This results in an error:
Problem 1
- Root composer.json requires me/my-package 0.1, found me/my-package[dev-main] but it does not match the constraint.
I have also tried:
"require" : {
"me/my-package" : "dev-main#0.1"
}
(This was an idea taken from How to use a specific tag/version with composer and a private git repository?). This goes through without any errors but:
$ composer show | grep me/my-package
me/my-package dev-main My Package
What is the correct way install a specific version of a package when developing it locally?
Probably the only thing why you hit this message is that you have "type": "path" and not "type": "vcs".
This is that Composer will only refer one version and only one version dev-main. The reason is:
If the package [path repository] is a local VCS repository, the version may be inferred by the branch or tag that is currently checked out. (ref)
You have the main branch checked out at /home/me/packages/me/my-package (/home/me/packages/me/my-package/.git/HEAD content is ref: refs/heads/main and /home/me/packages/me/my-package/.git/refs/heads/main points to the git revision) and composer will only take that one.
You should have no problem to make that change from path to vcs given:
You already have a (git) repository at /home/me/packages/me/my-package (looks so by your question)
You know the absolute path on your local system to that repository (again, looks so by your question: /home/me/packages/me/my-package).
Given these two points, Composer is able to obtain the VCS tagged versions from that path. So basically only the change of the "type":
"repositories" : [
{
"type": "vcs",
"url": "/home/me/packages/me/my-package"
}
]
Just take care that "url" contains the absolute path (and there is a git repository at that place). Likely already all set in your case, just saying.
Git is very prominent that's why I mentioned it here, for other types of VCS Composer also has options at hand. The details - also for git etc. - are available here:
VCS - Repositories (getcomposer.org)
I would like to provide a button from github to directly deploy an app.
Its a go application which serves some website.
Now for persistent data it requires an addon "Heroku Postgres".
I tried defining a heroku.yml with:
setup:
addons:
- plan: heroku-postgresql
I tried app.json with:
{
"addons": ["heroku-postgresql:hobby-dev"]
}
But it does nothing at all, it never adds the addon. I know I can add it manually through the website or CLI, but I want a fully automatic way - if that is possible.
It should look something like this
"addons": [
{
"plan": "heroku-postgresql",
"options": {
"version": "12"
}
}
]
Example app.json from heroku
When a build a conda environment like this
conda create --prefix env python=3.6.5
Some absolute paths appear in some json files in the conda-meta folder. How can I avoid it? I just want to use relative paths here or I just want to hide them completely. Is there a way to achieve this? Are they mandatory? See extracted_package_dir, source or package_tarball_full_path attributes:
{
"arch": "x86_64",
"build": "py36_0",
"build_number": 0,
"channel": "https://repo.anaconda.com/pkgs/main/win-64",
"constrains": [],
"depends": [
"python >=3.6,<3.7.0a0"
],
"extracted_package_dir": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"features": "",
"files": [
"Lib/site-packages/certifi-2019.03.09-py3.6.egg-info",
"Lib/site-packages/certifi/__init__.py",
"Lib/site-packages/certifi/__main__.py",
"Lib/site-packages/certifi/__pycache__/__init__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/__main__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/core.cpython-36.pyc",
"Lib/site-packages/certifi/cacert.pem",
"Lib/site-packages/certifi/core.py"
],
"fn": "certifi-2019.3.9-py36_0.tar.bz2",
"license": "ISC",
"link": {
"source": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"type": 1
},
"md5": "e1faa30cf88c0cd141dfe71e70a9597a",
"name": "certifi",
"package_tarball_full_path": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0.tar.bz2",
"paths_data": {
"paths": [
[...]
If I remove the whole folder the environment become useless and I cannot activate it anymore in order to install, update or remove new packages.
I want to do this to encapsulate the environment in one application and I do not want to have my original absolute paths in the computer of the final user.
My Use Case
I am developing an electron app that uses a tornado server (that uses python)
Currently I am using electron-builder to add the environment to the installer and works pretty well, but one drawback is the conda-meta folder I commented above. What I do now is to remove it manually when I want to make an installer.
That will probably break conda. It's not written to treat those as relative paths. If you told us more about your use case, maybe we could help. Are you trying to redistribute an installed environment? Have you see the "constructor" or "conda-pack" projects?
Finally the best solution I found was to ignore the folder when creating the final installer with electron-builder.
So I have applied the directive extraResources to add the conda environment except the folder conda-meta. And I have added the filter "!conda-meta${/*}", the meaning is explained here
Remember that !doNotCopyMe/**/* would match the files in the doNotCopyMe directory, but not the directory itself, so the empty directory would be created. Solution — use macro ${/*}, e.g. !doNotCopyMe${/*}.
The result in the package.json file:
"extraResources": [
{
"from": "../env",
"to": "env",
"filter": [
"**/*",
"!*.pyc",
"!conda-meta${/*}"
]
}
],
We are using custom repositories that are not held on Packagist, and thus need to use composer's "repositories" key:
{
"type": "vcs",
"url": "https://github.com/name/repo"
},
However we also want to develop these locally before pushing them to GitHub
{
"type": "vcs",
"url": "/path/to/repo"
},
{
"type": "vcs",
"url": "https://github.com/name/repo"
}
However if a new user downloads the repo and just wants to use from GitHub (maybe they won't be developing locally) they get a big red error:
[InvalidArgumentException]
No driver found to handle VCS repository /path/to/dir
Is there a way that composer can tolerate this and just move down to the next line where it will find the repo?
That this is possible right now, as far as I know. The defined "/path/to/dir" needs to exist, it needs to be a repo and the repo needs to contain a composer.json file, otherwise Composer will fail.
Sounds like a valid point for a PR to ignore an invalid repository definition but not sure what Jordie thinks of this ;)
As an alternative: You could set-up your own Satis repo and pull the package from there.
I've got own bundle "MyBundle" with composer.json:
{
"name": "mybundle",
"require": {
"propel/propel-bundle": "1.1.3",
"friendsofsymfony/user-bundle": "dev-master"
},
"autoload": {
"psr-0": { "": "src\" }
},
"target-dir": "MyBundle/"
}
When i'm trying to check it out with composer ("mybundle": "dev-master"), everything is ok, but it's on "no branch" branch.
How can i set a branch ("master") for installed bundle?
That's not possible due to the way composer installs work, and the fact it needs to be able to install specific versions of a branch. When you do that git ends up in a headless state.
If you need to work inside that installed bundle and push some commits just make sure you git checkout master before doing that. If you forgot and committed your changes you can also just checkout master and then merge the changes you did on to it.
Update: Composer now checks out branches by name if the commit you checkout matches the last commit of the branch.