We have a package from a private repo that we don't wish to be accessed by everyone. Problem is, when others run composer install it will inevitably fail.
To save us sharing keys or telling other developers to comment this line out every time, is there a way to tell composer to safely skip this package?
Just so you know this is a module required in the live environment so require-dev will not work in this case.
Related
In my composer.json file I like to list all compatible versions of the (example) package x/y as possible in the require section. Typically that would look like "x/y": "8-10". If I execute composer install, composer of course installs the newest available version of x/y which is 10.x and that is fine, almost always. But sometimes I want to install version 8 of x/y just to check that execution of my application is still possible with version 8.
Another scenario is when a client reports a bug and has version 2.10.4 of some example/dependency whereas the newest would be 2.14.2. The example/dependency is not required by my application directly but transitively by x/y. So I just for a moment want to install my whole dependency tree with version 2.10.4 of example/dependency to debug it with that version of the library.
Of course a temporary modification of the composer.json so that it requires these exact versions would work but that approach seems unnatural, complex, and implies the risk of accidentally committing the modified composer.json to version control and thereby creating a huge mess.
I thought about modifying the composer.lock because accidentally committing a modified version of that wouldn't really cause a problem. But is it okay/recommended to modify the composer.lock file for such purposes?
Ideally I would want a command line argument that fixes some library to some version just for one execution of the composer install command without modifying composer.json.
Since install is meant to read from a lockfile, this option wouldn't make sense for the command.
But for update (and if there is no lockfile, install behaves as update), there is the --prefer-lowest flag (docs).
There is also the option to downgrade a specific package without affecting your composer.json file, by running something like:
composer update --with vendor/package:2.0.1
Mind you, any of these options will modify your lockfile, so after testing you would probably need to git restore composer.lock to go back to the original state.
Commiting a lockfile for a project by mistake should be a biggish issue. Since applications are usually built/deployed by reading the lockfile, a lockfile in an inconsistent state could break things in unexpected places.
But warding of commiting and pushing changes by mistake seems to be excessive, IMO. Developers can make changes to any file, and if they commit those "by mistake", things can break all around.
Expecting a basic "I should look what's changed before staging and commiting" seems a very low bar to me.
I have a bit of an issue, I have a Go project that I depend on (DPkg) and this project has some small dependency on another package (TPkg).
For some reasons which is irrelevant to the question I am not able to build TPkg at the moment however I know that I do not ever use the parts of DPkg that call TPkg so I went ahead and recreated a fake DPkg in my vendor folder.
The issue is that whenever I run dep ensure, dep will attempt to handle this package. I have attempted setting an ignored constraint on it in my Gopkg.toml but then dep just deletes my code in the vendor folder. I have also tried further adding a prune.project constraint to mark TPkg as unused-packages = false but that does not prevent dep from deleting the package.
Is there any way that I can tell dep to ignore TPkg completely and by that I mean, don't attempt to change it or delete it?
I know what this means and how bad it is in terms of issues and maintainability but that is not the question at hand here.
This may be a stupid question but after a fair bit of googling i and still unsure weather i should be removing the the composer.phar file after installation. Is the files just part of the installation or required to run the application ?
The Composer executable is used to manage your dependencies, which is mostly "update" and "install". The result is an autogenerated autoloader and a complete tree of files from the required packages of the application.
The executable itself is not part of the application and therefore is not needed to run it. For security reasons it should not be present on the live servers unless you really know it has to be there, because it seems like a good idea to not give an attacker some useful tools into their hands.
The proper places to have the executable are your development environment (in order to add new packages and update the old ones) and the deployment server that puts the application onto the live server (otherwise you cannot install the packages that your application runs with).
I know that people tend to create a workflow that simply pushes a branch to production, and a post-transmit hook then runs composer install, but this is dangerous from a reliability standpoint: What if Github has an unexpected downtime and you push to production, unable to download the new packages? In this scenario, the server doing the deployment actually is the production server and so requires a copy of the Composer executable, but I explained that this is no ideal setup.
I am working on a Laravel project and it's working fine. But
Recently I have updated Composer by composer update and Composer updated successfully.
Then I have removed unnecessary packges from the vendor folder. I have also removed paragonie folder from vendor, which is unwanted for me.
This gave me following error.
Fatal error: require(): Failed opening required '/var/www/laravel/vendor/paragonie/random_compat/lib/random.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/laravel/vendor/composer/autoload_real.php on line 54`
I have added this folder and working fine.
Any one can help me to figure out what is purpose of paragonie folder.
Why it is included?
Composer manages every package inside the vendor/ folder. You simply can't remove any folder from vendor/ without breaking something. Don't do this!
If you want to remove packages from your project then edit your composer.json and perform a composer install.
There might be some packages in your vendor folder that are not required from your composer.json. This is because ever package can have it's own requirements. If you delete one of these required packages you break it.
There is generally NO necessity to remove anything from vendor!
Note: composer update does NOT update Composer itself. It updates every package of your project! To update Composer itself use composer self-update.
I really recommend you to read the composer docs or some tutorial on how composer works for a better understanding of composer.
Don't manually edit composer.json, or the file-structure of the vendors folder. The vendors folder contains the dependencies and their dependencies.
The most important part about this is that you should not EVER edit a project dependency within a project. The second you do, you have broken future updates, This is a terrible thing.
If you feel this is not possible because a library needs changes, I'd suggest taking a breath.
Most libraries have some built-in configuration options, or methods of modifying the library. If they don't then maybe contribute some, or fork the library.
You can absolutely make changes to any library that has a permissive license towards source code modifications, that is why open-source code exists, but you need to do this in the right way.
You can possibly improve the code by forking using source control, which will also allow you to submit a pull-request(PR) to the package maintainers.
The benefit of trying this is that IF the package maintainers decide to accept your changes, you will be up-to-date with all of their future updates, even if you do not have time to maintain your changes, someone will probably pick them up and make their changes.
IF your PR is not accepted; I would strongly consider revisiting your initial assumptions so that you can be sure the decisions you are making are the only way, or the most beneficial way forward. Either way; it won't matter, as you can keep your fork as the version you pull from in future and either add it to packagist (only if you are really more people will benefit from it); or telling composer to pull directly from your repository (it does have to be on the internet AFAIK).
If you have to fork, you will need to ensure you can maintain the dependency, and this is accepted within your organisation. If it's you then in future, you can manually update from time-to-time from the original source library; to ensure you still enjoy the benefits of the core library, whilst keeping your changes.
THIS IS THE DIFFERENCE BETWEEN HIGH-SCHOOL CODING AND PROFESSIONAL DEVELOPMENT.
sorry for shouting / exclaiming, but this needs to be put out there more, possibly in 100ft letters somewhere.
Resolving this problem folowing these steps:
go to your project from terminal (CLI)
cd vendor
svn add paragonie
svn commit -m ""
And if another file is missing do the same thing.
For me it works 100%.
Good luck.
I am working on laravel 5.1 project. I have updated few files for customization e.g. vendor/laravel/framework/src/Illuminate/Foundation/Auth/AuthenticatesUsers.php file. It needed to install new package so I had modified composer.json and run command 'composer update' and package was installed but all the code I had updated in AuthenticatesUsers.php file was replaced with original.
How to prevent this over-writing while updating composer?
You are not supposed to edit files in the vendor folder if you also want to use Composer to easily update your dependencies. Editing files of external packages effectively means you are forking that project and maintain it yourself. This either means you only apply your change once and then stop all further development, or you constantly have to check for updates of the original package and merge their changes with your changes.
I am pretty sure there are ways to solve the underlying problem with adding changes to existing files, but your current question suffers from the XY problem - you want to add a change to Laravel but don't know how to do properly, find that editing may solve the problem, but now need to prevent overwriting that file, and ask about preventing that overwriting - instead of asking how to add change to Laravel classes.
A nice and clean solution would be to fork the repository and add it to packagist. Then simply change the composer dependency with your version of improved (so to speak) laravel's source code.