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.
Related
One of the brilliant aspects of Firely.Terminal is its ability to interoperate with the local FHIR package cache (~/.fhir) in a way that is fully compatible with HAPI tools using the cache. Sadly, that no longer seems to be the case.
Today I updated Firely.Terminal to version 2.4.2 and it seems that the new version walks all over the FHIR package cache, changing files without having been asked to.
It used to be that the only thing Firely.Terminal changed in existing packages was the generation of a missing .index.json. For newly installed packages, the only difference to a HAPI-installed package was some additional fields in .index.json (presence of some fields containing null which would normally be suppressed, and the addition of a fhirVersion field).
When the new Firely.Terminal is told to add a package to a scope (fhir install) it automatically 'bakes' it, which seems to involve things like snapshotting all StructureDefinition resources and expanding all ValueSet resources. Even resources whose content remains unscathed get their timestamps trashed. The same fate befalls all packages that are listed as dependencies in the manifest of the package being added to the scope.
There is an 'unbake' command (e.g. fhir unbake --package kbv.ita.for#1.0.1) but this does not operate recursively. What's more, when it says 'Bake successfully removed from KBV.ITA.FOR#1.0.1' (note the erroneous capitalisation) then that is an outright lie - the contents of the package directory are completely unchanged, except for the removal of the file .bake.json.
Hence the only way of restoring the package cache to working order is to identify all trashed packages, delete them all, and then reference them with some HAPI tool in order to get them re-cached.
I wouldn't mind so much if Firely.Terminal trashed its own cache. But what it destroys is the global HAPI package cache for the current user, and that is simply not acceptable.
Is there any way of suppressing the destructive behaviour of Firely.Terminal? Ideally globally (with machine-wide effect), but a secret command switch would do in a pinch. If that is not possible: does anyone know which of the older versions is the newest that still works, and where to get it?
Note: if the cached packages are write-protected then Firely.Terminal doesn't take the hint - it tries to clobber the files anyway and spews out oodles of 'access denied' messages. What's more, it doesn't even stop when an error occurs; instead it continues on its merry way and trashes everything that one might have forgotten to write-protect.
Background: one of the properties of the FHIR package cache that is important for our work is that the files in the cache are exactly the same as those in the (normative) published packages. In particular, we need profiles published without snapshots to not contain snapshots, value sets published without expansions to not contain expansions and so on. For one thing, this makes it possible to verify that the cached files are exactly the same as those contained in the published packages (or fixed versions thereof). For another, we need to control the context in which profiles are snapshotted, value sets expanded and so on because it may be necessary to supply dependencies that are different from those declared in the package manifest. The latter is sometimes necessary because the profile/package version management in the context of electronic prescriptions in Germany is a bit, erm, peculiar and can diverge from FHIR standards. For this to work at all the resources must be snapshotted/expanded dynamically (depending on the use context), not statically on disk. Things are moving in a more standards-compliant direction but we are not quite there yet.
Latest version without bake (on install)
From some quick testing of the latest versions of Firely Terminal, it seems 2.2.0 is the latest without bake functionality (and auto-bake on install). Installation instructions:
> dotnet tool uninstall --global Firely.Terminal
> dotnet tool install --global Firely.Terminal --version 2.2.0
Baking
The bake functionality has been introduced to provide packages with snapshots, because not all downstream tooling (most notably sushi) are able to generate these themselves.
Currently bake might be a little too aggressive by default, also recalculating snapshots for packages that already have them. In principle, this should not be a problem since snapshots are a just a cache for the calculation of all the layered differentials. Since snapshot logic still evolves it might even be desirable now and then to recalculate. But in newer versions we will look to:
Change the default to not recalculate when already provided
Provide a global setting to change that default to never calculate/always (re)calculate snapshots
This should prevent Firely Terminal from touching any files that don't need touching in the package cache. I'm not sure from your question if there was anything broken in the state of the shared FHIR cache after 'baking', given your use of 'thrashing' and 'destroying'?
Unbaking
The unbake command is intended to remove snapshots from a folder of packages. I see in my testing that it's not doing that, which I'll take as an issue to fix.
I went to do a fresh update server deployment of an application (via -full.nupkg) the other day and was surprised to see that the file does not exist in my dist folder. I've run through and rebuilt on Windows, but I'm only getting the .exe and unpacked folder versions.
I can't recall when I last did a full build with .nupkg deployment, it may have been a few months. I've tried rolling back any changes that I could think of that are related (other than electron-builder itself, which I can't roll back any further as it has a critical bug fix in it for us for one of our platforms).
My next thought was a bug in electron-builder or that they removed that feature. However, I don't see any current bugs about it, and the documentation I've run across (while being a bit vague) at least seems to suggest that it's still available.
I did see some references to an "electron-builder-squirrel-windows" module as a recommendation too, but I can't actually find that module. Is that what I need/what broke? If so, where can I find it?
Please set target to squirrel. To use Squirrel.Windows please install electron-builder-squirrel-windows dependency.
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.
I wonder what I should be carefull of updating PHP on Windows(with Apache). My current version is 5.2.9-2
My php folder is simply under C:\php
If I simply download and unzip the new version, 5.3, which is a little more significant than going from 5.2.8 to 5.2.9, I'm thinking I need to be carefull not to overwrite some files.
I'm thinking 5.3 will have some changes in the .ini file. My .ini file allready has some modules activated and such, but if I leave the old .ini file, I might have some incompatibilities.
So, what incompatibilities and other risk do I need to look out for? I don't have any experience updating this, and I fear I might loose things and will just end up having to delete and make a clean install and then edit everything again, which is painfull.
Don't do it on a live environment until you've tested.
Php 5.3 contains enough changes/new stuff that i would be wary of either issues with the server config, as you've suggested, but also enough that I'd want to test my app to check it still worked correctly under 5.3 as well.