I know that if I want to suggest some library in my composer, I can do this.
"suggest": {
"vendor/library": "A description"
},
But, is there a way to suggest for require or for require-dev? Could I simply add a comment for this?
The description in the suggest line can be used for anything you want the developer to see, including suggestions on whether to require the package for development.
On the other hand, the differences between require and require-dev are few. Both get installed by default. You'd only interfere if you don't want to install that 100 MB "development only" package that will never ever get used in your production code and wastes precious space on the server.
Related
I'm using OroCommerce and want to add a new packge using composer require
Before install my wanted package, composer display message like this
Reading composer.json of {package_name} ({version})
Composer seems to read all version of all my installed package.
It take so many time to read all version (by example package oroinc/platform have 199 releases)
There is a way to prevent this behavior
I answer myself (in case someone as the same question)
It's no possible https://github.com/composer/composer/issues/5943
I have done a bit of digging through the rubygems code and it doesn't look like there is a built-in way to get it to not throw a Gem::ConflictError even if there is one. During development I might be wanting to test something that I know is not going to touch the code from which the conflict is coming or I know that the whatever version of the erstwhile conflicting gem isn't going to cause a problem. I just want to get on with testing what I want to test and I'll worry about version conflicts later.
I know I can hack rubygems to do this. I can think or multiple ways to get it done. I'm just kind of curious if anyone has already done this, how they did it, and maybe if that code has been shared somewhere. I'm also a bit curious as to why this isn't built in to rubygems as a development tool.
You need to worry about version conflicts now before you can get anything done. As Ruby has a singular root namespace and every dependency gets loaded there it's generally not possible to load multiple versions of the same gem. Other systems like NPM for Node.js are significantly more flexible, it's possible to load any number of versions at the same time, so if you're used to that you'll need to adjust your expectations.
If you're trying to do testing and you want to avoid resolving a conflict, just remove that gem requirement from the Gemfile temporarily.
Ultimately you'll have to fix things, there's no way around it, but you can always be selective about what you require.
If you really know what you are doing, try this:
export NOEXEC_DISABLE=1
ruby you-program.rb
This environment variable will disable search and check for Gemfiles and gem versions.
Whenever I try to add a new package using composer like
"composer require packagename/package" or use "composer.phar update", I am getting all the installed packages updated. Is there any option in composer to exclude some package that I don't need to get updated?
run this command and see what is your package version:
composer show -i
go to composer.json and edit which package you want never change by composer update and write version correctly for that :
"jacopo/laravel-authentication-acl": "1.3.*",
change to :
"jacopo/laravel-authentication-acl": "1.3.11",
Done! now if you run composer update this package not update.
From my experience, the best way to exclude 1 or some packages is to use --interactive in composer update.
$ composer update --interactive
When you do this you can select which package you want to update and skip the package that you don't want to update.
You can supply the name(s) of a one or more packages to update:
composer update vendor1/package1 vendor1/package2 vendor2/*
and this will only update those packages.
This isn't specifically excluding, it's including, but it certainly makes updating specific packages much faster.
To avoid the update on using the require command, you'd could hand-craft the composer.json, (which isn't so hard) then run the above targetted update on the package you just added.
Also use --no-dev to exclude development packages (if you are not developing the packages you are depending on e.g. in production). This also speeds up the dependency analysis.
If you feel the need to exclude some of your packages from being updated, I'd consider this the beginning of getting into a dependency mess. You should clean up your dependencies now before it gets worse.
From my experience, the topmost reason not wanting to update a dependency is when you used a branch of a package instead of a released version. You should try to fix this as thoroughly as possible:
If you are using your own packages, tag a release version for the commits you want to use. Then switch your software to either use that exact version, or use a wildcard version requirement like 1.0.*, ~1.2 or ^1.3.4.
If you are using external code that you cannot influence directly, try to contact the developers of that code and ask them to tag a version. Tagging versions is important to maintain a sane dependency tree.
If you cannot make the external developers tag a version, find a way to tag it yourself:
Clone their repository on Github, tag a version, and include your copy of the repository instead of going to packagist.org.
Create the necessary metadata in a "type=package" repository entry in your composer.json file.
Or at the very least, when depending on the branch, assign it a version alias to allow for a smoother transition later when the external project starts tagging their versions. Note that this will not fix your current problems at all, but it may make things better in the future.
If all else fails, you might point to a certain commit id in your composer.json. This will
In general, you should always be able to run composer update unconditionally. If not, this is a warning sign for dependencies not properly declared in your own composer.json file.
The second reason for not wanting to update is incompatible changes in a package that were tagged as a bug fix instead of a major version increase. The solution for this would be simple:
First you'd have to investigate the reason for such an error: Was it really an incompatible API change? If yes, raise an issue with the developers of that package. They should create a new bug fix version with that incompatible update rolled back or fixed, and if they want to keep their change, they should tag it with a minor or major version increment, depending on what they changed.
If however you incorrectly used their code, somehow not using the public API, a bug fix is unlikely. You should try fixing your code by not using stuff that is not supposed to be the public API. For example, in recent versions of Symfony, the public API is explicitly tagged in the code and documentation - using something else will break at some point, even when doing "compatible" version updates like from 2.6.x to 2.7.x.
Another way to fix it would be to exclude the newer version inside the composer.json file: Instead of "external/package":"~1.2" you'd put "external/package":"~1.2,!1.2.5" if you find that version 1.2.5 broke your software. Or maybe you are afraid of further updates also breaking your software, you'd put in "external/package":"~1.2,!>=1.2.5".
One more thing to add: If you run composer require, you won't get updates for packages that are already installed. They are fixed. The required package will be selected based on all the installed versions, and it will only be installed if there is a version available that is compatible with all the versions already installed. Note that this will not work correctly if there are dependencies on branches of packages in both your own composer.json and the new package. The reason is that the branch name will be the same, but you'll never know which commit was being used. Maybe the new package uses a very recent commit of dev-master of a third package, and your own software a very old one, and there have been incompatible changes in between - this will break things without Composer being able to detect it.
Using composer require packagename/package, you require a new package and you get a partial update for just packagename/package and its dependencies.
composer update packagename/package can be used to trigger the same partial update, but then in case you already have packagename/package in your composer.json.
One workaround is to use replace property, however there isn't dedicated command for that, so you can run composer require foo/bar as usual (which will create composer.json), then add a new replace section for the package to ignore.
Or create composer.json file on your own. Here is the example:
{
"require": {
"radic/tmp-underscore-php": "1.2.0"
},
"replace": {
"patchwork/utf8": "*"
}
}
Once you run composer install, the required package patchwork/utf8 won't be downloaded.
I'm making a custom application using Laravel. By default Laravel generates a composer.json file like the following:
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
}
Is it good practice to change the name, description, license etc on my project?
More info: I am developing this project for another company. They will use it internally (as a public website) and may or may not hire a different developer in the future.
To be honest, changing it provides no real benefit unless you're planning to release the project as a composer projects that allows people to run composer create-project you/yourproject.
There's no real rule around changing if you plan to keep it internal only, but there are two arguments, one for and one against.
Changing it keeps it simple, and gives developers working on your project a nice little source to some basic information.
Keeping it as the default allows you and other developers to access some basic information about the systems creation.
So ultimately, it's entirely up to you.
Yes, you should edit it to reflect the current state. At least delete info that you don't want, like the MIT license (you probably don't want to license proprietary code that way), the keywords, description and name.
Maybe in the future, composer create-project will deal with it more properly (the source project needs to have a name to be identifiable, but creating a project almost never needs to keep that name) - but this also won't help you with existing projects.
Keep that meta data correct (at least delete incorrect data) - you never know the benefits. Personally, I hugely like having the right project names because that name gets displayed on my Satis pages as "projects using this package", i.e. the reverse dependency - so I know what to update if I change a library.
Currently I am writing a Ruby on Rails application, and I am using Gems, however sometimes I feel that Gems are not as flexible as I want them to be. To make them more flexible. Should I
Fork them on github, and customize it, but this still present the challenging of managing everything.
or
Strip and merge the code of the gem to the main application? This will allow further customization of the gem. This would be for situations where a Gem require another Gem's functionality.
or is there a better way of doing this?
Thanks
B
Choice A is the better answer for a number of reasons.
You get to merge in security updates, enhancements, and bug fixes easily.
Your changes may get merged into the core--in fact, consider if you could implement them in such a way as they live alongside the core functionality as options. If this happens, you have the ultimate win--nothing to maintain, and you can retire your fork.
Others can benefit from your changes.
Your project's footprint is kept smaller and focused by keeping the gem code isolated.
You'll have something to add to your Github "resume."
If its some kind if not so popular gem or "bicycle" from some previous studio or developer who started project(in my case).
I prefer deprecate this gem's and move code into project,
for example they have c***la-deploy - it's just wrapper to Capistrano 2 with own methods))) - I just delete it and rewrite on last Capistrano 3
Than that have own "CMS" c***la-cms where they wrap standard form_for or simple_form with name "twitter_form_for" ? - fist of all I start try to find gem who use this name, and than find in dependency gem's ...
Its take a lot of time for new developer involve in project - better move to standard rails methods/heplers
But anyway i understand for a what this studio do that - its just vendor lock and for client more hard to move out from them to another developers.
For example for startup its bad to use a lot of dependencies and if it's just simple website - dose not matter.