I'm attempting to use the npm package pdf-image (https://www.npmjs.com/package/pdf-image) for an app that is deployed on heroku. It requires imagemagick ghostscript poppler- (ensure you have convert, gs, and pdfinfo (part of poppler) commands).
I've attempted to add a imagemagick, ghostscript, and poppler buildpack to the app and then deploy. The app is working but times out (h12 heroku error) when it comes to the method that requires the pdf-image package.
The method works locally without problem.
I'm not sure how to trouble shoot. I see that there are a lot of different options to use for the buildpacks and am wondering if I added the best one or not.
Has anyone deployed to heroku with the pdf-image package?
Which buildpacks do you recommend for ghostcript, imagemagick, and poppler?
What are other possible causes for the time out and ways to troubleshoot?
Thank you!
Depends on what heroku stack you're using.
https://github.com/Fieldwire/heroku-buildpack-poppler
This buildpack has worked for me on heroku-18 stack. You can find more buildpacks here .
Also you may check here if the library is not installed already on your server and what version.
For example the imagemagick and ghostscript are already there since cedar-14 so you don't need to add that buildpack.
Related
I'm trying to automate the task of downloading mp3 files from a web site and uploading to another web site. With Puppeteer, I'm able to do this with the following code.
// ... Download the file and save locally
// Sets the value of the file input to fileToUpload
inputUploadHandle.uploadFile(fileToUpload);
// ... submit the form
This works fine on my Mac. I can download the file and upload it through the form submit. When I deployed it on Heroku, I'm aware that Heroku's ephemeral file system will save the file to /app folder. And I'm even able to send that saved file through NodeMailer as an attachment.
But on my Heroku app, when Puppeteer submit the form, the file is not uploaded as it should be. The submit happens as if the file is not selected.
I know I can have work arounds like grabbing the file from my own server. But I'm still curious why this happens. What makes Puppeteer uploadFile to fail on Heroku?
By the way, here are two links that might help with the background:
Practical Puppeteer: How to upload a file programmatically
puppeteer-heroku-buildpack
The solution: if you want to use uploadFile, don't use Puppeteer version 2.1.1, for now stick to 2.0.0. In your package.json:
"puppeteer": "2.0.0"
I checked recently and found out that uploadFile is still broken in Puppeteer 5.5.0.
Here's the detail. When I develop on my Mac, I didn't specify a version for puppeteer. But I happened to be using a version in which uploadFile works. However, every time you push to Heroku, Heroku will check your package.json to install all dependencies. In my case, Heroku updated to the latest version (by the time of this writing 2.1.1) which broke the uploadFile function.
Even though I printed out the Chromium version early on and noticed that Heroku is using a higher version, it never occurred to me that I should test with an older version of Puppeteer. Instead, I spent a lot of time testing other workarounds, which all failed. Any way, once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.
I'll post an issue on Puppeteer and hope this to be fixed in the next release.
I am deploying and ember-cli app to heroku and pretty much everything is working as hoped. The only issue is that when the app precompiles, it adds a fingerprint to images and assets as expected but does not add them to the asset reference within a stylesheet. Specifically, I have a couple of images as background images in stylesheets that when deployed can't be found due to the addition of the fingerprint to the file. How do I either get the fingerprint added to the asset path reference in the stylesheet or tell ember/heroku to not add fingerprint to any files? Thanks for the help.
A little late getting back to this but I ended up just disabling the fingerprinting for now by adding this in the Brocfile.js
var app = new EmberApp({
fingerprint: {
enabled: false
}
});
You just need to upgrade to the latest version of Ember CLI. From version 0.1.3 of Ember CLI there's no need to disable fingerprint. I think it's fixed by this pull request.
According to Ember CLI guide steps to upgrade to the latest version of Ember CLI are included with each release and can be found here.
Before upgrade, I had issues with Lightbox2 and Fancybox(image assets). After upgrade, all references to fingerprinted assets are applied correctly.
I'd like to run a Meteor.js app with the "spiderable" package on Heroku. Is there a buildpack or anything else to deploy it on Heroku? (PhantomJS in needed)
This buildpack (which I wrote) works with Meteor > 0.9.3 and includes phantomjs:
https://github.com/AdmitHub/meteor-buildpack-horse
I don't know how you're stuck with this, since in practice it's pretty straightforward to install an NPM module as shown in this guide. You only need to swap underscore in that example with phantomjs.
A very good buildpack to use is oortcloud's meteorite buildpack. I've used the meteor-only buildpack, but I've encountered way to many issues with it, but with the aforementioned I have had no problems with it so far.
As for the spiderable package, meteor add spiderable.
Fair warning though: running Meteor on Heroku requires alot of research on how to actually run your app, especially with providing correct environment variables. If you will have a problem with that, this would probably not a good place to discuss any of that.
On a side note: Next time, I implore you to be a little more clear about your problem and specify what your goals really are, and what have you tried so far. Seriously, who upvotes these things?
I want to use Node.js as a Share.js server and Ruby for the frontend. As far as I know, Heroku only allows one web-facing process called "web". Does anyone have some experience trying to do something like this?
No, Heroku detects the application type when you push your code to Heroku and it compiles the slug. You'd need to have them as seperate applications with a defined API between the two (not always a bad thing)
UPDATE: You can 'stack' buildpacks these days, eg Ruby + PHP so you could have both executed. See https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app for how to use multiple buildpacks in the same app.
As a caveat, you technically can install two languages on a single app — but I'm not sure about running them concurrently. I made this buildpack to combine NodeJS and PHP (so that I could run Grunt during the slug compilation):
https://github.com/gcpantazis/heroku-buildpack-php-gruntjs
The language detection is usually fairly dumb; it'll be looking for a file indicative of the lang, i.e. index.php or a rakefile. You'll have to change the detect bin so that your code will pass.
Update:
Even better, consider using https://github.com/ddollar/heroku-buildpack-multi ; it'll let you install buildpacks sequentially. Depending on your application you might need to find language buildpacks that don't have verification steps, i.e. checking for a package.json file in a NodeJS app.
Yes, it is mostly possible I believe, as long as you're not doing something very tricky. I once deployed a Flask (Python) app that used Stanford's CoreNLP - which is all written in Java. You will need heroku-buildpack-multi.
After adding this, make sure to make a .buildbacks file and add all the buildpacks you will be needing from the Heroku github.
This circumvents Heroku detecting your app type itself and makes it install all necessary buildpacks from the .buildpacks file.
I've got a ruby web app that uses lilypond to generate sheet music based on user input. I'd like to move the hosting to heroku (I've recently used heroku on a few projects and really liked it, plus my traffic is low enough that it'd be free host it on heroku, for a while at least). However, heroku's dyno architecture doesn't allow you to ssh in and install whatever packages you want...instead, you give it a gems manifest, and it will install the gems for you.
So, if I'm going to deploy to heroku, I'm going to need to package lilypond as a gem. I've released a few pure-ruby gems, but haven't dealt with native extensions or precompiled binaries, or anything like that.
Is it possible to take some precompiled binaries and package it inside a gem? Ideally, this would include binaries for OS X (which I develop on) and debian linux (which is what's running on heroku), and would install the proper binary when the gem was installed.
it is possible, since precompiled binary gems for windows are the norm. Take a look at rake compiler, perhaps.
also https://github.com/rdp/ruby_tutorials_core/wiki/gem (https://en.wikibooks.org/wiki/Ruby_Programming/RubyGems) might help
-r
I think you've got a few options here:
You could get the Lilypond source and package it into a gem with a native C extension. There are some useful guides on how to do that at http://guides.rubygems.org/c-extensions/ and http://patshaughnessy.net/2011/10/31/dont-be-terrified-of-building-native-extensions
There's also a gem called gitara but I haven't been able to find any information about using it on Heroku. It might be worth emailing the author and asking if he knows anything about that.
You could create a Heroku buildpack that installs Lilypond as part of your deployment. I wasn't able to find any for Lilypond, but there are plenty of examples that do similar things - for example, this one installs Imagemagick (which is included by default on Heroku, so probably not necessary anymore - but hopefully the code is helpful). More documentation at https://devcenter.heroku.com/articles/buildpack-api and https://devcenter.heroku.com/articles/buildpack-binaries
Based on my reading, I think the buildpack option is the best way to go.
Hopefully this helps!
Instead of precompiling, you should be able to just list the gem in your .gems file, see the Heroku documentation. Of course, this requires your gem builds the native code correctly - this is still a task, but hopefully an easier one.