Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle METEOR_PACKAGE_DIRS #188

Open
eric-burel opened this issue Jan 13, 2018 · 9 comments
Open

Handle METEOR_PACKAGE_DIRS #188

eric-burel opened this issue Jan 13, 2018 · 9 comments

Comments

@eric-burel
Copy link

eric-burel commented Jan 13, 2018

Type of problem
  • Build wrong packages
Summary
Contents of .meteor/release
Buildpack version
https://github.com/AdmitHub/meteor-buildpack-horse.git
Deployment target

Heroku

Hi,

I can't have METEOR_PACKAGE_DIRS to be taken into account during app build/run. It is set to /app/.submodules/my-repo/packages and the folder exist, I checked out in the bash.

However, it behaves as if ignored, I guess during build the path is different (e.g I should write /tmp/.submodules/... instead of /app or simply ./, could not test yet) but I am not sure and I can't find a solution. Maybe the buildpack is a good place to handle this ?

@SachaG
Copy link

SachaG commented Jan 14, 2018

Did you see http://docs.vulcanjs.org/#Git-Based-Deploys ?

Unless I'm wrong, Heroku deploys work by pushing your git code to the server first, the buildpack only takes over then. In that context METEOR_PACKAGE_DIRS makes no difference, you'll always only deploy what's inside the git repo no matter what.

@eric-burel
Copy link
Author

eric-burel commented Jan 15, 2018

Hi @SachaG , I think it is a bit more complex on Heroku, I think you don't simply push your app on the server and run it. E.g your app is built in a tmp/foobar/ folder or smth like that and then moved by Heroku to /app/, but Heroku doc is complete crap and I can't clearly be sure of what happens.

The submodule (here Vulcan libs) is correctly pushed to Heroku along with the app in /app/my-vulcan-libs/, but METEOR_PACKAGE_DIRS=/app/my-vulcan-libs/packages seems incorrect, as if the files were not yet available at build time. So it is never found by Meteor, and thus the main app load the packages from Atmosphere instead.

I'll share a doc as soon as I get it working. But of course maybe it is not related to buildpack, I may miss something else.

@SachaG
Copy link

SachaG commented Jan 15, 2018

Don't you deploy with git push? Or is there another way?

@eric-burel
Copy link
Author

Yes I deploy git push, but Heroku does a lot of thing then, I don't know exactly where I push on the server. The /app/ folder does not seem to be the orginal pushed repo, but only a built copy, it does not a contain a .git. It is still a bit unclear to me though.

@SachaG
Copy link

SachaG commented Jan 15, 2018

Well if you deploy with git push only the things committed inside your git repo will be pushed to Heroku.

@eric-burel
Copy link
Author

Yep the submodules are indeed commited, Heroku loads them according to the .gitmodules and confirm it in the log when I push. It is is the first thing Heroku does, so that all code is present during build.
I have even checked with heroku run bash, the main app and its subrepo containing Vulcan are there in the /app folder, and METEOR_PACKAGE_DIRS points to the correct dir (checked with a cd METEOR_PACKAGE_DIRS).

It's simply that the /app folder seems to be where the files are after build, but not during build, hence the fact that the METEOR_PACKAGE_DIRS gets ignored, it points to files that do not exists yet (but will exist after build, too late). At least this is how I understand it for the moment.

I'll try with a relative path instead instead asap.

@SachaG
Copy link

SachaG commented Jan 15, 2018

Yes but what does METEOR_PACKAGE_DIRS have to do with git submodules?

@eric-burel
Copy link
Author

The submodule is my fork of Vulcan, containing slightly patched libs (e.g to fix the CORS issue with Cordova). So Heroku clone this fork automatically along with my app, and METEOR_PACKAGE_DIRS points to its packages folder, so that I use my fork of Vulcan instead of the Atmosphere package, as I do locally.

eric-burel referenced this issue in eric-burel/vulcan-docs Feb 5, 2018
Hi,

I drafted a 2-repo deployment for Heroku. However, it does not work yet, I think that the `METEOR_PACKAGE_DIRS` is incorrect though I can't fix it, as [described in this issue](https://github.com/AdmitHub/meteor-buildpack-horse/issues/188](https://github.com/AdmitHub/meteor-buildpack-horse/issues/188
)

Also, I have no idea how you would handle a private repo for the custom Vulcan packages. However most of the time you'll use this kind of install either to enjoy the latest PR before they are merged into Vulcan or on the opposite to keep old versions of the packages, so I guess very few people will need to hide their packages code in a second private repo, they'll use the usual install process instead and put those private files directly into their app code.
@PranavKhadpe
Copy link

@eric-burel I noticed you've brought up this issue on several buildpack repos. I have the exact same issue right now where I have a local version of a meteor package in my app under the packages directory. When I try deploying to Heroku, I keep getting an error that there is an unknown package in top-level dependencies which I'm guessing is coming from meteor not recognizing the local package. Had you found a solution to this issue? Alternatively, is there a platform to deploy to other than Heroku that handles this better?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants