How do I find out what is holding my app up from updating? I keep getting the 'This project is at the latest release which is compatible with your current package constraints.' message.
Here is the output from the update command:
Refreshing package metadata. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
This project is at the latest release which is compatible with your
current package constraints.
My packages.js looks like so:
# Meteor packages used by this project, one per line.
#
# 'meteor add' and 'meteor remove' will edit this file for you,
# but you can also edit it by hand.
accounts-base
accounts-password
alanning:roles#=1.2.9
arunoda:npm#0.2.6
ch-activity
ch-activityreport
ch-arrestreport
ch-assetreport
ch-citation
ch-fieldinterviewreport
ch-incidentreport
ch-inspectionreport
ch-location
ch-media
ch-narrative
ch-organization
ch-person
ch-property
ch-signature
ch-vehicle
cmather:iron-router#0.8.2
coffeescript
copleykj:mesosphere#0.1.9
d3
dash-patrol
email
less
mizzao:bootboxjs#4.2.1-master.1
mrt:accounts-ui-bootstrap-3#=0.3.3
mrt:leaflet#0.3.8
mrt:mongo-counter#1.1.0
notices
sacha:spin#2.0.4
standard-app-packages
tsega:bootstrap3-datetimepicker#=0.2.0
I have migrated all the ch-* and dash-* packages to the new format. Those are local, in app, packages. Those cannot be in public repositories.
Try replacing
cmather:iron-router#0.8.2
with
iron:router#0.9.1
in your packages file.
I'm think it may be because not all your packages are compatible with Meteor 0.9.0
If you want to check what packages are currently compatible enter this code:
meteor search (Package Name)
By default meteor will only return compatible packages, so you can find which packages aren't working by searching each one. If you can't find the package, then its probably not compatible and you aren't going to be able to run the latest version of Meteor unless you remove it.
Don't worry though! While Meteor 0.9.0 is quite buggy, they are working hard to update all the packages and patch the bugs. Just give it a few weeks to sort itself out if that doesn't work :)
Best Of Luck! Hope This Helped!
Meteor search is included in the latest release. Docs: http://docs.meteor.com/#meteorsearch
Try running this command and you should be able to access meteor search
meteor update
Also, the update should tell you if there's a package update available, although I had to run update (packagename) on each starred package for it to update
meteor update aldeed:collection2
I found that I had to remove my ~/.npm directory and run meteor again to resolve some npm dependencies I had. Perhaps you have some npm dependencies as well?
Related
First of all, I can't use composer because Im under a corporate network. I tried everything to get composer working :
HTTP_PROXY, HTTPS_PROXY, HTTPS_FULLURI ... Nothing is working. Composer diag gives an OK status for http packagist but FAILS for https connectivity. The error it gives me is:
SSL : Handshake timed out.
But that's not my question, I spent to much time trying to get composer working (But if you got a solution, you'll make my day )
My real question is the following : How to install bundles manually
I want to install this bundle : http://knpbundles.com/pierredup/MenuBundle.
What I did to try installing the bundle :
Registering the bundle in appKernel.php :
new \CS\MenuBundle\CSMenuBundle()
Tried to add it in the autoload.php :
$loader->add('CS', __ DIR __.'/../vendor/CS/CSMenuBundle.php');
(Dont know how to add php code properly ... )
But it doesn't work, got the following error :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for another namespace?
And then, even if it is not a good practise, I tried to add it to autoload_namespaces.php and did a dump-autoload after that :
'CS\MenuBundle' => array($vendorDir. '/CS/')
I still have an error, but not exactly the same one :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for "CS\MenuBundle\CSMenuBundle"?
Now I'm a bit frustrating, I saw many posts (not on Stack) where people scream because we have to use composer to manage dependencies. I totally agree with that, but I can't, so I'm trying to find another way, and as I can't find any clear tutorial which explains how to install vendors without composer, here I am.
Note that I commented on the problems I see with your approach on your question directly.
However, I looked at the package you want to use to see if there would be ANY chance installing it somehow (preferring Composer). I don't think it is possible or feasible.
composer require customscripts/menubundle:dev-master - this would be the easy command for Composer to do everything. However there are problems:
The package you want to use is not registered on packagist.org, so there is no way to simply use Composer on a machine properly connected to the internet, grab the packages, zip them and transfer them to the place you need it.
To work around this, you'd manually add the repository to the composer.json file - this might actually work (however it takes way too much time on my VM). You'll end up with code that was last edited in the year 2012!
The dependencies of that code will likely not work anymore. The composer.json of that package lists "require": {"knplabs/knp-menu-bundle": "dev-master", "symfony/framework-bundle": ">=2.0,<2.3-dev", "jms/di-extra-bundle": "1.1.*"} - even the first "knplabs/knp-menu-bundle" will never work. Remember that the code of this package is from 2012 - now we are in 2016, so "knp-menu-bundle" has seen four years of development on the master branch. There simply is NO WAY of knowing which commit had been used of this package. You'd have to reverse-engineer this lost information.
Additionally, you see why Composer is awesome and doing it manually is bad: In addition to your wished package, you have to download the three additional packages mentioned here.
But detecting packages that have to be added is a recursive task: knp-menu-bundle has a dependency on knp-menu (with no further dependencies) and symfony/framework-bundle (already added). symfony/framework-bundle itself has a dependency on 9 more Symfony packages and doctrine/common... and so on. You have to detect every single package of this and download the correct version manually if you cannot use Composer.
Skipping your original package because that installation wasn't finishing while I was typing my answer, I tried to install knp-menu-bundle to see how many packages would be installed. Composer installed 20 packages, some of them using Symfony in 2.8 (it SHOULD be compatible with Symfony 2.2 stuff, shouldn't it) - and I simply ran composer require knplabs/knp-menu-bundle:1.1.1 to grab a similarly old version of knp-menu-bundle from 2012.
The strength of using Composer is that it supports rapid development by allowing updating quickly, downgrading reliably (if you commit your composer.lock file and always use tagged versions), and simply allowing to add new packages instantly. Not being able to use Composer is a very severe limitation for you as a PHP developer. Talk to your boss or team lead about your company's situation with the HTTPS proxy, and find a solution to use Composer. The alternative is to develop everything from scratch on your own or waste plenty of hours trying to fiddle with manual downloads that don't fit together easily.
It is rather tedious when trying to get dependencies of local Meteor packages up-to-date.
Currently, they are specified in package.js like and I have to check for latest version of each dependency used and update manually.
E.g.
api.use([
'alanning:roles#1.2.14',
'aldeed:simple-schema#1.5.3',
'aldeed:collection2#2.8.0',
'iron:router#1.0.12',
'useraccounts:iron-routing#1.12.4'
]);
Can meteor-tool do this or is there a better way to update packages' dependencies, especially useful when you have multiple local packages in a project.
There is no real value in bumping the dependency version in package.js, as I mentioned in my comment. It could lead to the counter effect and break version resolution.
The expectation is to mention the minimal compatible version (with the same major version number). When your local package is updated, its .versions file is updated as well, which may hint the build system which version of the dependency is the preferred one to use (the one that your package was built with).
The closest thing that I can give as an answer is this quote of David Greenspan* taken from the Meteor forums:
We have made some small improvements to meteor update over time, but
we don't have a way for a package to ask for one of its dependencies
to be upgraded more aggressively. meteor update with no arguments will
take patch updates to indirect dependencies, but not minor versions. I
recently improved the messages that meteor update prints, so in the
next release, it should tell you if an indirect dependency is not at
the latest version after it runs (rather than printing the very wrong
message "All packages are at their latest compatible versions").
If you bump the minor version of a package, I think the expectation at
the moment is that you will republish the packages that depend on it
if you want their users to get the new version (after running the
tests to make sure all is well).
So, when the author of a package you depend on releases a new:
patch version: no need for you to do anything. The new version should be used automatically.
minor version: check that everything works and release a new patch version, as to acknowledge the new version.
major version: things are expected to break. Make the required changes and release according to semver rules.
I would not count on things behaving as they do right now, as the packaging system undergoes pretty significant rework in order to be more compatible with NPM (including the ability to directly require NPM packages from Meteor apps and packages), expected to be included in v1.3.
* (actually, Sacha Greif posted the quote).
This is from the docs:
In general, you must specify a package's version (e.g.,
'accounts#1.0.0' to use version 1.0.0 or a higher compatible version
(ex: 1.0.1, 1.5.0, etc.) of the accounts package). If you are sourcing
core packages from a Meteor release with versionsFrom, you may leave
off version names for core packages. You may also specify constraints,
such as my:forms#=1.0.0 (this package demands my:forms at 1.0.0
exactly), or my:forms#1.0.0 || =2.0.1 (my:forms at 1.x.y, or exactly
2.0.1).
So the answer is, it will not update your package.js script but it will download the latest compatible versions, depend on your settings.
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 was trying to get an example an working from this tutorial: http://g00glen00b.be/meteor-twitter-streaming/
Here's the Github url: https://github.com/g00glen00b/meteor-twitter-stream
It was written in Meteor 0.7 and it requires some packages so the instructions say to do this:
mrt add semantic-ui
mrt add npm
mrt add streams
mrt add momentjs
However, I have Meteor 0.9.4 and since 0.9 we're not supposed to use meteorite anymore, just add packages directly with the "meteor add #package#" command.
The problem is that none of the packages needed by this project can be found (npm, semantic-ui,streams,momentjs). I tried asking the original author of the code but he needs time to look into it.
So I thought I would ask the community. Any ideas?
Thanks for your help
During the package migration to 0.9, many packages were automatically migrated under the mrt user. Thus, meteor add mrt:<package> might work.
The best way to find the package you're looking for is to search for it on Atmoshpere, e.g. https://atmospherejs.com/?q=semantic, https://atmospherejs.com/?q=moment etc.
So your install instructions should become:
meteor add nooitaf:semantic-ui meteorhacks:npm arunoda:streams mrt:moment
Note that Arunoda is no longer maintaining streams, so you might want to look for an alternative.
locate the package here
or by typing:
meteor search semantic
meteor search moment etc...
more information regarding this matter: here
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