New error when pushing to Heroku about heroku-buildpack-meteor

[dabeeeenster]

Think this is due to 0.6 - http://install.meteor.com/ no longer has reference to VERSION anywhere which I think the buildpack expects?

[dimfisch]

Any idea how to solve this?

[dabeeeenster]

Not really - you could try hard coding the URL of the 0.6 meteor install package - the URL is https://d3fm2vapipm3k9.cloudfront.net/bootstrap/0.6.0/meteor-bootstrap-Linux_i686.tar.gz

---

Ben Rometsch (http://flavors.me/dabeeeenster) - Director
Solid State Group (http://www.solidstategroup.com/)
Tel: [phone]

On Friday, 5 April 2013 at 17:38, dimfisch wrote:

Any idea how to solve this?

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

[jordansissel]

Looks like the meteor folks completely rewrote their install script, so the 'compile' script for the buildpack will need to be fixed to compensate.

[dimfisch]

Thanks, Jordan. Any idea how soon this can be done? Any help needed? (not that I think I can help much, but still, I'd be willing to give it a shot :)

[jordansissel]

No ETA for me, probably would be easy for someone to patch though.

[dimfisch]

Any chance you could spend a few minutes with me on Skype to give me a sense of what needs to be done and how?

[madsmao]

I have been looking at this. I tried hardcoding the version number into compile and that got me past the initial error. However, I then got this sucker:

Unpacking meteor
Building meteor bundle
/tmp/buildpack_2wunkdrmnx0zj/bin/compile: 41: meteor: not found
tar: /app/tmp/repo.git/.cache/bundle.tar.gz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
tar: Child returned status 2
tar: Exiting with failure status due to previous errors

As far as I can see it might be related to the path, but I really am guessing here. I'll do some more hacking in the morning.

[madsmao]

On a side note: it really would make sense to detect the appropriate version of meteor for a given project, instead of just assuming that you want the latest version.

[dimfisch]

Totally agree. I'm developing on Windows, so still on 0.5.9

[jordansissel]

Indeed; open to support for that. Probably worth looking into how the ruby buildpack does it (which I believe has version selections)

[dabeeeenster]

@madsmao given that the meteor project itself is now doing this it would seem like the right way to go. There's also a hard dependency on that install.meteor.com script which is a shame as it could break this project in the future...

[madsmao]

I am still working on fixing this issue. I appreciate any support on this issue, as I am a total noob when it comes to buildpacks (the debugging workflow has it's quirks).

I am currently at a point where I feel the need to pretty much start from scratch and embrace the new features introduced in Meteor 0.6.0 for version control etc.

@dabeeeenster you are right that the hard dependency on install.meteor.com is not cool. I pretty much see two ways to avoid this:

1. Embrace the install script and use it as a part of the build pack
2. Check out the source from Github and do a full build

The first approach will probably make the build script run faster, whereas the second approach might cause less issues down the road if the Meteor team decides to make changes to install.meteor.com. I'll go with the first option for now (if I can get it working) because I believe it is the fastest path to a working buildpack.

[madsmao]

I now have a working buildpack that supports 0.6.0. Feel free to take it for a spin!

This app is running on the new buildpack: http://v8s-bp.herokuapp.com/
The buildpack is here: https://github.com/v8squirrel/heroku-buildpack-meteor

CAUTION: This is very much a work in progress. I have yet to test that stuff like database access actually works, but I thought I would let you guys know. It's also worth mentioning that my changes will probably make the buildpack incompatible with earlier releases of Meteor.

I'll continue my work on this and keep you guys posted.

[madsmao]

I have made a bit of a mess of my commit history (tried to clean all my 'Random commit' messages out of the log). Hope things will still work for everyone.

[adnissen]

Have you tested it with the database stuff? I'd like to use this, but I'm slightly worried that it'll just break everything in my db since you mentioned it.

[madsmao]

I tested it with a database and everything works as expected. Can't hurt to do a quick backup first though.

[dimfisch]

Just to be clear, this is just for 0.6.0, any other version won't work, right?

[madsmao]

Correct. Older versions won't work. Future versions should though.

[dimfisch]

Would it be complicated to add support for 0.5.9?
Basically have the buildpack work just like it did 5 days ago...?

[madsmao]

Making the buildpack work like it did 5 days ago (just for 0.5.9) should be possible by creating a fork of @jordansissel's code and simply hardcoding the version number into bin/compile. That should do the trick.

[dimfisch]

Wow! As simple as that, huh?!
So that means replacing

PACKAGE=meteor_${VERSION}-1_amd64.deb

with

PACKAGE=meteor_0.5.9-1_amd64.deb

?

[madsmao]

Yeah, that should do it. Give it a try :-)

[madsmao]

Also, you can comment out the line(s) that fetch information about the version number from install.meteor.com.

[dimfisch]

Didn't work, I got the following error:
Unpacking meteor ar: /app/tmp/repo.git/.cache/meteor_-1_amd64.deb: File format not recognized

I don't think it likes the dots in that file name.

On your second reply, which lines are you referring to?

[jordansissel]

you can make it tunable using an environment variable to set the version instead of querying it from meteor.com; this would let you use heroku config to set the version of meteor.

[jordansissel]

I can probably cobble together a hack that supports you setting METEOR_VERSION

[jordansissel]

Looks like heroku buildpacks have changed behavior?

tar: /app/tmp/repo.git/.cache/bundle.tar.gz: Cannot open: No such file or directory

Looks like CACHE_DIR isn't valid anymore? Wonderful times...

[jordansissel]

I've confirmed master of this buildpack repo now works for meteor apps.

[jordansissel]

I'll have a go adding 0.6.x support too

[jordansissel]

Best I can tell, 'heroku config' environment variables are not exposed to the 'compile' step

% git push heroku 
...

GIT_DIR=.
HOME=/app/
LOGNAME=u26769
LOG_TOKEN=t.9e79a5be-dfa2-446e-9f83-f6b4ebbc4eb7
MAIL=/var/mail/u26769
PATH=/tmp/build_1iup2aqv2o9qp/.meteor/local/usr/bin:/tmp/build_1iup2aqv2o9qp/.meteor/local/usr/lib/meteor/bin::/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin
PWD=/app/tmp/repo.git
SHELL=/bin/bash
SHLVL=1
SSH_CLIENT=10.4.18.11 40679 49712
SSH_CONNECTION=10.4.18.11 40679 10.227.3.45 49712
USER=u26769
_=/usr/bin/git-receive-pack
Fetching meteor deb package

[jordansissel]

Based on the above, I do not know if it is possible to make the version of meteor configurable.

I expected the 'ruby' buildpack to show signs of version choosing, but it does not. Even the Ruby buildpack, which is probably 'state of the art' in terms of buildpack practices, says that if you want to change the version of something to fork the buildpack and edit the hard-coded versions in the config.

[jordansissel]

• the buildpack is now pinned at version 0.5.9 until someone provides patches to make 0.6.0 work
• based on research, I believe heroku buildpacks are not featured enough to permit passing parameters to a buildpack.

Marking closed.

[metadaddy]

If it's useful, there's a Heroku Labs feature that lets you set env vars during slug compilation: https://devcenter.heroku.com/articles/labs-user-env-compile