I am trying to use Swift Package manager to update my dependencies locally to match those in the Package.resolved file.
For example, when I update my dependencies I run swift package update, which updates the Package.resolved file, which I then commit. When I pull this new commit on to a computer that has an existing .build directory with the old versions of the dependencies I would like to update the local versions to the one in Package.resolved.
I was expecting swift package resolve to do this, but instead it updates the Package.resolved according to the .build/dependencies-state.json.
The obvious solution is to delete the .build directory, but this means the dependencies are recompiled every time, which can be slow on CI.
I want the equivalent of bundle install, yarn install, or carthage boostrap. Is this possible?
This has been confirmed to be a bug, and I have opened a bug in the Swift JIRA.
Related
I'm working with a copy of Symfony (2.8.9) which works perfectly on my development server.
I've cloned the same repository that this server pulls from, down to my local, and updated composer / ran the Symfony installer. I started getting an error:
You have requested a synthetic service ("request").
I did a little research, and found that this is a bug in the next version of Symfony, 2.8.10, as reported here:
https://github.com/symfony/symfony/issues/19840
I will await the bug being fixed in 2.8.10, but in the meantime, I'd love to be able to downgrade from 2.8.10 to 2.8.9, so my local copy runs and matches the copy on my development server.
I've seen posts regarding changing the version numbers in composer.json, but all my numbers related to Symfony say "2.8", with the minor version number excluded. Additionally, my composer.json file matches on both my dev server and local.
Should I add the minor version number ".9" to the end of the composer.json dependencies, and install the dependencies with composer? Is it enough to add the minor version number to only Symfony-related dependencies, and have all other dependencies work correctly, or are there other version numbers that should be changed as well? Is my approach correct, or is there another way to do this entirely?
You can edit just one line in your composer.json:
"require": {
...
"symfony/symfony": "2.8.*, !=2.8.10",
...
This way, you tell Composer to avoid that specific version. All other dependencies will be retrieved automatically.
Important: you have to remove your composer.lock file first, as Composer will complain that you're locked to the very same version you're trying to avoid.
Disclaimer: backup and test first. I tested on a base Symfony install, not sure if other package will complain.
I am using local Meteor package for my app (not posted on Atmosphere.js).
When I update this package elsewhere, I proceed with the following:
Update version of the package.
Delete old package from /packages/ directory of the live app.
See my program search for packages 3(?) times and then crash:
Your app is crashing. Here's the latest log:
Errors prevented startup:
While selecting package versions:
error: unknown package in top-level dependencies: vladimir3000:testpack
Your application has errors. Waiting for file change.
Copy new package with new version.
See my app picking up the changes and going live again:
vladimir3000:testpack upgraded from 0.0.2 to 0.0.3
=>Meteor server restarted
Is there a way to avoid step 3 and more elegantly instruct meteor to replace one package with another. Meteor update would not work as the package is not on atmosphere.js. Or hot swap is something from SOA world not from blood and fibers of Meteor javascript?
You can simply paste over the files for the package.
When you delete the old package, Meteor sees a file change and rebuilds the app. Since the package no longer exists in the packages directory, Meteor will try to pull it down from Atmosphere since it sees that there is a dependency on vladimir3000:testpack in .meteor/packages.
It will attempt to resolve this dependency a few times, with each build failing because the package you are referencing is unknown.
You can stop meteor and delete and replace the folder. Or you can copy and paste over the folder. The second method is preferable because Meteor will simply rebuild with all of the new files, rather than rebuilding and trying to resolve the dependency using Atmosphere.
I searched and got answers on using CocoaPods but really i couldn't manage to use it because i didn't what they mean
1- Install CocoaPods 0.39.0 or later. -> i did install it using sudo command
"I stopped here, didn't know what to do"
2- In your Podfile, add use_frameworks! and pod 'RealmSwift' to your main and test targets.
3- From the command line, run pod install.
4- Use the .xcworkspace file generated by CocoaPods to work on your project!
sorry my question looks bad but it is my first time to ask a question here :)
Your list of steps is correct, and assuming CocoaPods installed correctly, you will then need to navigate to the directory of your .xcodeproj file.
In that directory, you can run the command pod init which will create a .podfile in the directory.
You can then continue onto steps 2-4.
However, as of writing this response, Realm's current release doesn't support Swift 2.1. We are actively working on an update for 2.1, which you can follow on this Github Issue.
I'm developing a Meteor app that isn't yet in production, so I can afford to move quickly when adopting new package versions (useraccounts had a significant version bump a few hours after I'd integrated it, for instance.) This was what I thought meteor update was meant to accomplish. Yet when I run:
meteor update
from my project, I'm told that packages were updated but .meteor/versions remains unchanged.
I can upgrade the package by running meteor add someone:package#whatever, but this just shuffles the version dependency from .meteor/versions to .meteor/packages even though it seems to do the upgrade. I'm happy to lock versions down when I go to production, but it seems like in development I should be able to use the update command, especially as meteor list indicates that as a next step.
I've managed to upgrade all my packages by removing .meteor/versions and .meteor/local and running meteor update, but this seems messy.
I also found this issue but it was closed. Should it be reopened or should I open a new issue? I understand how semver works, but I think the issue is that Meteor isn't writing its constraint solver results to .meteor/versions so doesn't realize that package updates have been applied. Is that accurate or am I just misunderstanding something?
now u can simply do
meteor update --all-packages
Expanding on previous answers, you can update all packages with this:
grep -ve '^#' .meteor/packages | xargs meteor update
For the time being it looks like that you have 2 options for packages which have updates you wish to use:
remove and add the package of concern via meteor remove provider:package_name and meteor add provider:package_name
update packages with their specific version manually via meteor add provider:package_name#X.X.X
Meteor won't update packages unless you remove and add them #2500
You can also use meteor update provider:package_name
Easiest way is to delete the contents of .meteor/versions and then save. Next time you run meteor it will update all packages to the latest version.
Just tiny addition to #Meteorpoly answer:
You can also edit package version in .meteor/versions file manually and meteor will pick it up on next/current run
From Meteor docs: meteor update --packages-only
This command will update all the packages which are not built locally, has an update available and is also compatible with the meteor version you are using.
It seems that now
meteor update
is enough to update all packages
lets assume you wish to keep your meteor at your current release then issue
meteor --release foo update --all-packages
where foo indicates your current meteor release ... you can identify your release by looking at file
cat .meteor/release
which for me has content of
METEOR#1.10.2
so my current meteor release is 1.10.2 ... to leave alone my current meteor release yet upgrade all packages to match my release 1.10.2 then command is
meteor --release 1.10.2 update --all-packages
alternatively if you wish to fully upgrade to both latest meteor release AND that release's package upgrades then issue
meteor update --all-packages
I used packagecheck. It analyzed the project, showed me available updates and assisted the general update.
$ npm install -g packagecheck
$ packagecheck
I think updating Meteor might have broken my app. It was working, then I ran meteor update, and now it is not working. Can I do something like meteor downgrade?
Meteor 0.6.0 and above ships with a new distribution system. You can now pass the --release argument to any Meteor command and it will run against the requested release. For example, to bundle your app against Meteor 0.6.1, run: meteor bundle --release 0.6.1. Notably, this only works for post-0.6.0 releases.
If you want to pin your app to a specific release, run: meteor update --release <release>. This modifies the .meteor/release file in your app directory. Then simply run Meteor as usual. You'll still get notified when there's a new release available.
UPDATE: As of Meteor 0.6.0, this functionality is available without using Meteorite. See Avital's answer. (for versions > 0.6.0. To use functionality on versions less than 0.6.0 you can still use Meteorite:
If you want to control versions with your apps (so your existing app can still use an older version, or 0.57.1 (with the security bug fix) you can use meteorite: https://github.com/oortcloud/meteorite
Install it via npm install -g meteorite
Its also helpful with loads of other packages from http://atmosphere.meteor.com.
To control the version of your app edit your smart.json to something with:
{
"meteor": {
"tag": "v0.5.7"
}
}
Only the app you've already made will be affected & you can upgrade it when you're ready.
I have tried this and it is very hard. My best advice is to try and copy all the files from an app running the version you want, then paste your app's code in there.
There is no meteor downgrade command from its CLI. The best and easy way if you have version control like GIT, just undo your recent changes by git stash save, and run meteor again.
On Windows, I was able to effectively "downgrade" from a failed upgrade by editing the version number to a previous working release in the file:
C:\Users\Paul\AppData\Local.meteor\meteor.bat
You need to change it to a version which has a corresponding folder in: .meteor\packages\meteor-tool