Re: Gem Manifest deprecation
Hey David, thanks a lot for your reply. On Fri, Apr 6, 2012 at 8:51 PM, David Dollar da...@heroku.com wrote: The .gems solution was non-deterministic in the normal use case. If someone specified sinatra in their .gems file, they would often end up with a completely different version in production than they were using in development. Sure you could specify an exact version of every gem in your .gems file, but few people did and it's a huge pain to maintain. Yes, I understand how frustrating that would be. Would requiring specific versions solve it or you think people would keep making mistakes? Bundler splits dependency declaration into what the developer cares about (Gemfile) and an exact specification of each version that should be installed (Gemfile.lock). This maintains dev/prod parity without the maintenance overhead of curating a specific list of gem versions yourself. It also has the advantage of not being specific to Heroku. Understood. I may add that it has the disadvantage of requiring a very heavy dependency (Bundler), but I guess Heroku's best interest is to push for the standardization of Bundler, as it simplifies its operations. It would be great for me if the .gems manifest were supported in its strict version, but I understand I'm part of a tiny minority. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Gem Manifest deprecation
Hello, what's the reason for deprecating the .gems manifest in favor of Bundler's Gemfile? -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Gem Manifest deprecation
Hello Michel, I think this is a great example of heroku being ahead of their time. When .gems was introduced, there wasn't a way to specify gem dependencies in a ruby project. Back then, dependencies were a mess - heroku even had to run their own custom fork of rails. Now, the Gemfile is a common and standard way of specifying dependencies. There is a whole community adding features and documenting implications and nuances. It makes sense for heroku to drop their proprietary tool and go with the common one, no? That way they can dedicate their resources on other great stuff to give to us. just my take, Keenan On Thursday, April 5, 2012 at 12:50 PM, Michel Martens wrote: Hello, what's the reason for deprecating the .gems manifest in favor of Bundler's Gemfile? -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com (mailto:heroku@googlegroups.com). To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com (mailto:heroku+unsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Gem Manifest deprecation
Hey Keenan, thanks for replying :-) On Fri, Apr 6, 2012 at 2:48 PM, Keenan Brock kee...@thebrocks.net wrote: Hello Michel, I think this is a great example of heroku being ahead of their time. When .gems was introduced, there wasn't a way to specify gem dependencies in a ruby project. Back then, dependencies were a mess - heroku even had to run their own custom fork of rails. There were other means to define dependencies (for instance, Bundler was initially inspired by this library: https://github.com/djanowski/dependencies). I think Heroku's solution was very elegant, and continues to be. Now, the Gemfile is a common and standard way of specifying dependencies. There is a whole community adding features and documenting implications and nuances. It is true that there wasn't a standard before Bundler. What I think, and I guess most people will disagree with me, is that even though Bundler was imposed upon every Rails developer, it doesn't mean it is the standard for the rest of the Ruby community. Sure, I could go along with the masses and adopt Bundler, but it feels wrong because it is way out of my workflow. Bundler is a very big dependency, I don't like the idea of it being imposed on me. Just for reference, this is the tool we use for managing dependencies at the company I work for: https://github.com/twpil/dep It makes sense for heroku to drop their proprietary tool and go with the common one, no? That way they can dedicate their resources on other great stuff to give to us. It may makes sense for Heroku, I really don't know if they will lose clients by dropping support for the .gems manifest. I don't have the power to avoid that from happening, sadly. If it were up to me, I would stick to the minimalism of the .gems manifest and also support Gemfile, given that most of the applications deployed to Heroku are built with Rails. Thanks! -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Gem Manifest deprecation
There's always the option of making your own buildpack that reads the .gems file or that dep thing, or really whatever you want. On Fri, Apr 6, 2012 at 12:06 PM, Michel Martens sove...@gmail.com wrote: Hey Keenan, thanks for replying :-) On Fri, Apr 6, 2012 at 2:48 PM, Keenan Brock kee...@thebrocks.net wrote: Hello Michel, I think this is a great example of heroku being ahead of their time. When .gems was introduced, there wasn't a way to specify gem dependencies in a ruby project. Back then, dependencies were a mess - heroku even had to run their own custom fork of rails. There were other means to define dependencies (for instance, Bundler was initially inspired by this library: https://github.com/djanowski/dependencies). I think Heroku's solution was very elegant, and continues to be. Now, the Gemfile is a common and standard way of specifying dependencies. There is a whole community adding features and documenting implications and nuances. It is true that there wasn't a standard before Bundler. What I think, and I guess most people will disagree with me, is that even though Bundler was imposed upon every Rails developer, it doesn't mean it is the standard for the rest of the Ruby community. Sure, I could go along with the masses and adopt Bundler, but it feels wrong because it is way out of my workflow. Bundler is a very big dependency, I don't like the idea of it being imposed on me. Just for reference, this is the tool we use for managing dependencies at the company I work for: https://github.com/twpil/dep It makes sense for heroku to drop their proprietary tool and go with the common one, no? That way they can dedicate their resources on other great stuff to give to us. It may makes sense for Heroku, I really don't know if they will lose clients by dropping support for the .gems manifest. I don't have the power to avoid that from happening, sadly. If it were up to me, I would stick to the minimalism of the .gems manifest and also support Gemfile, given that most of the applications deployed to Heroku are built with Rails. Thanks! -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Gem Manifest deprecation
On Fri, Apr 6, 2012 at 6:06 PM, Peter Keen peter.k...@bugsplat.info wrote: There's always the option of making your own buildpack that reads the .gems file or that dep thing, or really whatever you want. That dep thing is a manager for the .gems file, not a different standard. I know I can have my own buildpack and I know I can do whatever I want, even use something other than Heroku. That was never my point, so your email doesn't help a bit. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Gem Manifest deprecation
The .gems solution was non-deterministic in the normal use case. If someone specified sinatra in their .gems file, they would often end up with a completely different version in production than they were using in development. Sure you could specify an exact version of every gem in your .gems file, but few people did and it's a huge pain to maintain. Bundler splits dependency declaration into what the developer cares about (Gemfile) and an exact specification of each version that should be installed (Gemfile.lock). This maintains dev/prod parity without the maintenance overhead of curating a specific list of gem versions yourself. It also has the advantage of not being specific to Heroku. Cheers, David On Fri, Apr 6, 2012 at 3:06 PM, Michel Martens sove...@gmail.com wrote: Hey Keenan, thanks for replying :-) On Fri, Apr 6, 2012 at 2:48 PM, Keenan Brock kee...@thebrocks.net wrote: Hello Michel, I think this is a great example of heroku being ahead of their time. When .gems was introduced, there wasn't a way to specify gem dependencies in a ruby project. Back then, dependencies were a mess - heroku even had to run their own custom fork of rails. There were other means to define dependencies (for instance, Bundler was initially inspired by this library: https://github.com/djanowski/dependencies). I think Heroku's solution was very elegant, and continues to be. Now, the Gemfile is a common and standard way of specifying dependencies. There is a whole community adding features and documenting implications and nuances. It is true that there wasn't a standard before Bundler. What I think, and I guess most people will disagree with me, is that even though Bundler was imposed upon every Rails developer, it doesn't mean it is the standard for the rest of the Ruby community. Sure, I could go along with the masses and adopt Bundler, but it feels wrong because it is way out of my workflow. Bundler is a very big dependency, I don't like the idea of it being imposed on me. Just for reference, this is the tool we use for managing dependencies at the company I work for: https://github.com/twpil/dep It makes sense for heroku to drop their proprietary tool and go with the common one, no? That way they can dedicate their resources on other great stuff to give to us. It may makes sense for Heroku, I really don't know if they will lose clients by dropping support for the .gems manifest. I don't have the power to avoid that from happening, sadly. If it were up to me, I would stick to the minimalism of the .gems manifest and also support Gemfile, given that most of the applications deployed to Heroku are built with Rails. Thanks! -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
