incompatible with [email protected] about meteor-roles HOT 43 CLOSED

Looks like the changes in Blaze are tripping you up. It is now

Package.blaze.UI.registerHelper

from meteor-roles.

👍 "all hell breaks loose" very true. I was very confused for a while after upgrading.

from meteor-roles.

The fix is very easy and straight forward not this alone, but more things are broken

in roles_client.js simple test for Package.blaze first

if(Package.blaze)
{
  _.each(Roles._uiHelpers, function (func, name) {
    Package.blaze.UI.registerHelper(name, func) 
  })
}
else if (Package.ui) {
  _.each(Roles._uiHelpers, function (func, name) {
    Package.ui.UI.registerHelper(name, func) 
  })
} else if (Package.handlebars) {
  _.each(Roles._uiHelpers, function (func, name) {
    Package.handlebars.Handlebars.registerHelper(name, func)
  })
} else {
  console.log && console.log('WARNING: Roles template helpers not registered. Handlebars or UI package not found')
}

from meteor-roles.

Looks like taking out of package.js

  if(uiExists()) {
    api.use(['ui'], 'client', {weak: true});
  }

and adding instead

  api.use(['blaze'], 'client');

helps

from meteor-roles.

Thanks for reporting this. Looks like 0.9.1 backwards compatibility is not exactly matching the release notes... There is a PR by @aldeed which resolves the issue for 0.9.1: #54

I won't be merging it in just yet because it breaks backwards compatibility but hopefully we can figure out a way to make it backwards compatible soon.

If anyone has suggestions on how to make a check for [email protected] similar to the uiExists one for the ui package, that would be very helpful!

from meteor-roles.

OK, I think its reasonable to use api.versionsFrom as a flag to see whether [email protected] exists so that should solve the backwards compatibility issue. I'll to some testing and hope to merge in @aldeed's PR soon.

from meteor-roles.

Asking for help on meteor-core:
https://groups.google.com/d/msg/meteor-core/s-xGYQ3gBkc/YJ1kBjjxAi8J

from meteor-roles.

It seems removing both the call to api.versionsFrom and any specific version for the blaze package gets blaze working for Meteor 0.9.0, 0.9.0.1, and 0.9.1.

  if (api.versionsFrom) {
    api.use(['blaze'], 'client', {weak: true});
    ...

Source: https://github.com/alanning/meteor-roles/blob/meteor-0.9.1/roles/package.js#L14

Please help test the meteor-0.9.1 branch, which contains @aldeed's PR plus backwards compatibility fixes. To use the version locally, clone the repo, switch to the meteor-0.9.1 branch, and manually link to the "roles" directory from your app's packages directory.

from meteor-roles.

meteor-0.9.1 branch works for me (meteor 0.9.1) - no issues so far. Thanks a lot.

from meteor-roles.

@Maxpain177, Repro steps? What version of meteor?

This works for me with 0.9.1 (with ~/tmp/meteor-roles on branch meteor-0.9.1):

cd ~/tmp
meteor create foo
cd foo
meteor add alanning:foo
mkdir packages
cd packages
ln -s ../../meteor-roles/roles roles
cd ..
meteor

from meteor-roles.

@alanning sorry. it works for me. just i used not latest version before

from meteor-roles.

meteor-0.9.1 branch works for me with [email protected]

from meteor-roles.

Any idea when the merge is ready? I would like to use this package in a project of mine with meteor-0.9.1 but i don't know how I can later deploy for a service like heroku (with heroku-buildpack-meteorite from oortcloud) using the specific branch for this version of meteor. Thanks

from meteor-roles.

Manuel, can't you just put the branched version in your local packages directory and then upload it? Later, if the patched version is available on atmospherejs you can remove the local version and redeploy.

Steffo

On 06.09.2014, at 18:27, Manuel Mateus [email protected] wrote:

Any idea when the merge is ready? I would like to use this package in a project of mine with meteor-0.9.1 but i don't know how I can later deploy for a service like heroku using the specific branch for this version of meteor. Thanks

—
Reply to this email directly or view it on GitHub.

from meteor-roles.

Thanks for testing, everyone!

Since it seems that the meteor-0.9.1 branch is working, you can expect a release to atmosphere later today.

@manuelmateus16, just as @steffow says. Meteor always uses the contents of the "packages" directory first before looking in its local package cache. So you would change to the meteor-0.9.1 branch then copy the contents of the "roles" directory into "packages/roles". This is also useful if you have private packages or something specific to your app that you want to always load first or keep separate for structure reasons. (Incidentally, this is also why meteorite ignores packages individually in "packages/.gitignore" rather than just ignoring the entire packages directory.)

@Maxpain177, no worries!

from meteor-roles.

@alanning, you might have discovered this already, but meteor publish command won't succeed without either api.versionsFrom call or specific versions specified for the core packages. Not good.

from meteor-roles.

Nuts... this is getting ridiculous.

Is there a way to release a version of a package to atmosphere targeted only to a specific version of meteor?

The docs are not helpful:

• https://atmospherejs.com/docs/publishing
• https://hackpad.com/Migrating-Packages-zN0we9sIjkH
• https://meteor.hackpad.com/Unipackage-tvas8pXYMOW#:h=Publishing-a-New-Package

I'll follow up on the meteor-core thread and see if anybody has a good suggestion.

from meteor-roles.

You can release to atmosphere from two separate branches using two separate version numbers, and then tell people in your readme which version to pin their project to based on which version of Meteor they're using. But that's very messy and you'll have to merge all fixes into both branches, release from both branches, keep the version incrementing straight, etc. Not ideal.

from meteor-roles.

Good idea! I won't be maintaining two versions but I can certainly do a spot release for 0.9.0 and then continue on with 0.9.1.

I think its the best option so far. The thing that worries me is later once other packages are depending on specific versions of roles and get upgraded automatically, potentially to a non-compatible version.

What a mess...

from meteor-roles.

Yeah, you pretty much just have to hope for the best and fix the specific dependency issues as they are reported.

from meteor-roles.

At this point releasing a new version would do more harm than good as more people are probably using Meteor 0.9.0 than 0.9.1. So I'm gonna hold off on releasing a new version on atmosphere until we figure out some solution that doesn't totally suck.

For now anybody that really needs this can symlink to the meteor-0.9.1 branch or copy it into the "packages" directory as described above.

from meteor-roles.

If you release a new version that depends on meteor 0.9.1 then people that use 0.9.0 won't be automatically updated to the newer version as the dependency of the new roles version is at 0.9.1 and they will only get the newer version of roles if they update to 0.9.1 or higher.

I don't see the harm in that?

And when you figure out a way to have roles work with every version of meteor, then just release a new version of roles with the fixed dependency and all people using roles will be updated to the newer version as the dependency is fixed or did something go wrong while I was thinking?

from meteor-roles.

Sure they will have to wait for a few bug fixes and features maybe, but only until you/we can figure out how to solve the dependency problem.

from meteor-roles.

@zimme, thanks for the explanation of the packaging system. That does resolve my worries about publishing a new version from the meteor-0.9.1 branch.

I'm a bit too hot-headed about this whole mess right now to make a good decision about how to handle maintaining the code so I'm gonna hold off on merging into master until I can think straight again.

I'll work on getting roles 1.2.13 for 0.9.1 released now.

from meteor-roles.

I'm about to release 0.9.1.1, which should actually guarantee backwards compatibility for renamed packages in the specific case of weak dependency. Apologies for the mess!

from meteor-roles.

Thanks @avital. If I'm understanding correctly, a new release of roles won't be necessary assuming all those using 0.9.1 upgrade to 0.9.1.1. Is that correct?

That would fix the specific issue for roles but please also consider the more general burden on package authors trying to maintain backwards compatibility, as referenced here: meteor/meteor#2531

from meteor-roles.

@alanning Almost. I tried using alanning:roles but it still printed the warning due to uiExists() returning false. I verified in a small test package that in general weak dependencies on ui will now work (you'll still find the expected symbols on Package.ui)

from meteor-roles.

(You can try running against the release-0.9.1.1 branch which is what's planned to get released.)

from meteor-roles.

I've verified that joshowens:accounts-entry works on release-0.9.1.1 (but not 0.9.1).

from meteor-roles.

I knew how to test against branches with meteorite but not with the new meteor. Can you point me to directions on running the release-0.9.1.1 branch, please?

from meteor-roles.

https://github.com/meteor/meteor/#slow-start-for-developers

Basically, you just clone our repo and run meteor from the top-level directory (after switching to the release-0.9.1.1 branch)

from meteor-roles.

@avital, can you suggest a way to support all versions of meteor (excluding 0.9.1) with a single codebase?

from meteor-roles.

I published roles v1.2.13 which supports 0.9.1 (and 0.9.1.1). I will maintain the meteor-0.9.1 branch for now until backwards compatibility gets sorted out.

I saw some wonky stuff when testing after I published but it seems to have stabilized now so I'm guessing the package caches were getting rebuilt. (0.9.0 apps were pulling in Roles v1.2.7, which is not compatible with 0.9+, meteor update updated meteor to 0.9.1.1 but didn't change the Roles version.)

For those who tested the branch, I think you just need to delete the "packages/roles" symlink or directory (depending on how you tested) and then run meteor update to pull in roles v1.2.13.

You should be able to see what version of Roles you are using by running meteor list.

from meteor-roles.

On Sep 6, 2014, at 19:55, Adrian Lanning [email protected] wrote:

I published roles v1.2.13 which supports 0.9.1 (and 0.9.1.1). I will maintain the meteor-0.9.1 branch for now until backwards compatibility gets sorted out

didn’t work with 0.9.1 but after a meteor update to 0.9.1.1 I was able to do a meteor add alanning:roles and ended up with 1.2.13 and all works.

Cheers!

Jan

from meteor-roles.

On Sep 6, 2014, at 20:01, Jan-Hendrik Mangold [email protected] wrote:

On Sep 6, 2014, at 19:55, Adrian Lanning [email protected] wrote:

I published roles v1.2.13 which supports 0.9.1 (and 0.9.1.1). I will maintain the meteor-0.9.1 branch for now until backwards compatibility gets sorted out

didn’t work with 0.9.1 but after a meteor update to 0.9.1.1 I was able to do a meteor add alanning:roles and ended up with 1.2.13 and all works.

Forgot: this was the error message with 0.9.1

 meteor add alanning:roles
Refreshing package metadata. This may take a moment.

alanning:roles: INCOMPATIBLE WITH METEOR 0.9.0 OR LATER

from meteor-roles.

That's probably the same thing I saw where it pulls in v1.2.7 for some reason. Not sure what's going on there. Maybe related to the bug @avital fixed confusing the constraint solver.

from meteor-roles.

Nice work. Thanks for fixing this so quickly, in spite of things being a bit unpredictable right now :)

from meteor-roles.

Thanks @jamgold. It's a bit disconcerting when suddenly your username is "breaking" everyones apps! Now I know why Chris changed iron-router's name to "iron:router"... :-/

from meteor-roles.

LOL

from meteor-roles.

Thanks for your effort @alanning!

from meteor-roles.

Also, thanks to @aldeed for the PR and @zimme for explaining more about the package system.

from meteor-roles.

TL;DR - does upgrading a package to Meteor 0.9.4 mean that those who try to install it from Meteor 0.8.x won't be able to? Or does meteorite fetch the older version from GitHub?

from meteor-roles.

I think the way the package system works is that only packages that are
compatible for your meteor version will be "visible". So meteorite will
only see the old ones that were published to the old atmosphere servers
(use "mrt add roles"). And "meteor add alanning:roles" will see the latest one
for your build (from the new meteor package servers).

Best to try it out on a test project though if you're worried it might
break your main app.

On Monday, October 27, 2014, Dan Dascalescu [email protected]
wrote:

TL;DR - does upgrading a package to Meteor 0.9.4 mean that those who try
to install it from Meteor 0.8.x won't be able to? Or does meteorite fetch
the older version from GitHub?

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

from meteor-roles.