On 08/10/2013 13:38, Jacob Carlborg wrote:
> On 2013-10-08 12:51, Bruno Medeiros wrote:
>
>>  From what I understand, for dependency graph locking to work at all,
>> then each package (as stored in the central package repository) would
>> have to specify its full dependency graph in the package specification.
>> So the foo package would have to specify not only the bar dependency,
>> but also xyz=0.0.1 as a dependency. Isn't that how it would work?
>
> No, now necessarily. Using Bundler it works like this:
>
> * You have your Gemfile, corresponds to package.json in dub
> * You run "bundle install"
>
> * When you do that it will create a new file, Gemfile.lock. This file
> contains the complete dependency graph of what it just installed.
>
> * Running "bundle install" when Gemfile.lock exist, it will read
> Gemfile.lock instead of Gemfile
>

Rigth, but then you would need to share the .lock file to the other machine you want to install/compile "foo" in. The repository alone would not be enough for that.

>
>> Rather, I think dub should adopt Semantic Versioning as part of its
>> recommended practices for package versioning:
>> http://semver.org/spec/v2.0.0.html
>> In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
>> upper bound on the version is required, to allow breaking changes in xyz.
>
> Semantic versioning helps, but it won't solve the problem. I wouldn't
> trust that a library actually follows the semantic versioning scheme.
> It's quite easy to accidentally add new API without incrementing the
> middle number. Or break the API.
>

Hum that is true. Especially without a tool that can verify API compatibility.


-- 
Bruno Medeiros - Software Engineer

On 2013-10-10 14:25, Bruno Medeiros wrote:

> Rigth, but then you would need to share the .lock file to the other
> machine you want to install/compile "foo" in. The repository alone would
> not be enough for that.

Yes, absolutely. In the Rails world it's recommended that you add both Gemfile and Gemfile.lock to the SCM for you're Rails applications. For Rails plugins you should only add Gemfile to SCM.

You usually don't have your Rails application uploaded to RubyGems.

-- 
/Jacob Carlborg

On Friday, 27 September 2013 at 06:49:39 UTC, Jacob Carlborg wrote:
> On 2013-09-26 13:39, Dicebot wrote:
>
>> No, you just let maintainers interested in target systems to take care
>> of it. And package for 2-3 you care about _personally_. It is an
>> obsolete idea that developer of a library/program should do any
>> packaging at all. If your program is any good, there will always be
>> volunteers to adapt it nicely for their beloved systems.
>
> How about doing a compromise. We add a new command to "dub" which will execute an installed package. Something like this:
>
> $ dub install foo
> $ dub exec foo --help
>
> This will by default look in the package.json file, in the current working directory, if it exists, for the correct version of the package to run.

I like the idea of a dub exec for when there is a tool you want to make use of during development.  Keeps everything nice and tidy and doesn't pretend to be an OS package manager.

+1