Dependencies for ryppl

[joe...@live.com]

I just started looking at this project while looking for a Boost mirror on GitHub.  The goals of the project look great, but I'm trying to understand the dependencies.

 

It looks like, if I want to build and link with a subset of Boost I'll need the following dependencies (assuming a Windows build):

• CMake for windows
• ryppl
• Python
• 0Install (including executables)

Agreed that some developers will have python already, but that just seems like a huge hurdle for adoption.

 

When I add my app to source control I only really want to add my CMakelists.txt and Boost submodules as a dependency.  That means any developer that intends to build my code will need the above installed.

 

Is this correct or am I missing something? 

 

Thanks

 

Joe

[Dave Abrahams]

on Mon Feb 04 2013, joewood-AT-live.com wrote:

> I just started looking at this project while looking for a Boost
> mirror on GitHub. The goals of the project look great, but I'm
> trying to understand the dependencies.
>
> It looks like, if I want to build and link with a subset of Boost
> I'll need the following dependencies (assuming a Windows build):
>
> CMake for windows
> ryppl
> Python
> 0Install (including executables)
>
> Agreed that some developers will have python already, but that just
> seems like a huge hurdle for adoption.

Heh. One of the great things about 0install is that it can "install"
all the other stuff for you. You just tell it what you want to run and
it downloads/wires-together all the dependencies on demand.

--
Dave Abrahams

[joe...@live.com]

But switching to a different installation mechanism is probably a show-stopper in an Enterprise environment.

What role is 0Install playing here?  Could you just pull the submodules together and run CMake?

Excuse the n00b question.

 

Thanks

 

Joe

[Daniel Pfeifer]

2013/2/5 <joe...@live.com>:

> But switching to a different installation mechanism is probably a
> show-stopper in an Enterprise environment.
> What role is 0Install playing here? Could you just pull the submodules
> together and run CMake?
> Excuse the n00b question.

Submodules (assuming we are talking about Git submodules) will not
work. Imagine your project depends on Boost.Filesystem and
Boost.System; so you add these two as submodules. Now,
Boost.Filesystem also depends on Boost.System; so there is a submodule
for it. You will end up with two copies of Boost.System, right? What
about circular dependencies?
We need to analyze the full graph of dependencies and then turn that
graph into a flat hierarchy.

[Mathias Gaunard]

Something that you can do with CMake using topology_sort.
Smart dependency resolution is only required if you have more advanced
dependencies such as exclusions and version requirements.

[joe...@live.com]

Yes, I understand the issue with submodules. C++ desperately needs a good package management solution.  The problem I think with this solution as it stands is the additional dependencies.

 

Now that Boost is modularized in GitHub couldn't a package manager use something like the libgit2 library to pull down the submodules directly? 

As long as each repo had a declaration of the submodule dependencies somewhere in a file it should be relatively easy to pull down the code and do a git subtree merge automatically http://git-scm.com/book/en/Git-Tools-Subtree-Merging.  This would avoid the duplication issues, combine to a single directory structure and allow you to run regular cmake.  

[Dave Abrahams]

on Tue Feb 05 2013, joewood-AT-live.com wrote:

> Yes, I understand the issue with submodules. C++ desperately needs a
> good package management solution. The problem I think with this
> solution as it stands is the additional dependencies.

What "additional dependencies?"

> Now that Boost is modularized in GitHub couldn't a package manager
> use something like the libgit2 library to pull down the submodules
> directly?

Yes it could, and it can. Of course, that's a dependency also. It
could also use dulwich, which is pure Python.

Using 0install has the advantage of serving the entire spectrum of
constituents, from Boost developer to end-user. It can download and
"install" source tarballs from GitHub, pre-built binary libraries,
dependencies such as CMake, and more.

> As long as each repo had a declaration of the submodule dependencies
> somewhere in a file it should be relatively easy to pull down the code
> and do a git subtree merge automatically http://git-scm.com/book
> /en/Git-Tools-Subtree-Merging.

I don't want subtree merges. I want to keep the source bases of
independent libraries modular and independent. You can write that tool
yourself if you want it for some reason, though ;-)

> This would avoid the duplication issues,

What "duplication issues?"

> combine to a single directory structure and allow you to run regular
> cmake.

Submodules don't cause a problem for regular cmake.

> On Tuesday, February 5, 2013 11:04:04 AM UTC-5, Daniel Pfeifer wrote:
>
> 2013/2/5 <joe...@live.com>:
> > But switching to a different installation mechanism is probably
> a
> > show-stopper in an Enterprise environment.
> > What role is 0Install playing here? Could you just pull the
> submodules
> > together and run CMake?
> > Excuse the n00b question.
>
> Submodules (assuming we are talking about Git submodules) will
> not
> work. Imagine your project depends on Boost.Filesystem and
> Boost.System; so you add these two as submodules. Now,
> Boost.Filesystem also depends on Boost.System; so there is a
> submodule
> for it. You will end up with two copies of Boost.System, right?
> What
> about circular dependencies?
> We need to analyze the full graph of dependencies and then turn
> that
> graph into a flat hierarchy.
>

> --
> You received this message because you are subscribed to the Google
> Groups "ryppl-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ryppl-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>

--
Dave Abrahams

[joe...@live.com]

The additional dependencies that I outlined above.  The need to install python, 0install etc...

In a corporate environment bringing in a new deployment tool like 0install would be frowned upon. 

 

A package manager that had integrated Git access and no other runtime dependencies is preferable for that very reason.  Like JavaScript's npm, it just runs pm v8 and that's it.

 

A sub-tree merge wouldn't touch the source base.  It's a way of overlaying submodules on top of other source without impacting each other (see the link below).  It's an alternative to consuming modular repositories without submodule dependencies.

[Dave Abrahams]

on Tue Feb 05 2013, joewood-AT-live.com wrote:

> The additional dependencies that I outlined above. The need to
> install python, 0install etc...

The user of this system doesn't need to install python or "etc." :-)

0install automatically pulls down all the additional stuff you might
need (including cmake) and caches it in a subdirectory of your home
directory. That includes any "optional" dependencies of Boost that
might not be in Git, such as libbz2, the OpenMPI libraries, doxygen, or
xsltproc. It doesn't "install" anything in the sense of disturbing your
system configuration. It simply puts things in a local cache.

> In a corporate environment bringing in a new deployment tool like
> 0install would be frowned upon.

Why? And what makes something a "deployment tool?" (I'm not sure I know
what you mean by "deployment").

> A package manager that had integrated Git access and no other runtime
> dependencies is preferable for that very reason.

Preferable to you perhaps, but much less useful to the community at
large, IMO.

> Like JavaScript's npm, it just runs pm v8 and that's it.
>
> A sub-tree merge wouldn't touch the source base. It's a way of
> overlaying submodules on top of other source without impacting each
> other (see the link below).

I know what a sub-tree merge is. As I said, I don't want it. I don't
see how it would confer any advantages for the problems we're trying to
solve. If you want it, of course, you can build it :-)

--
Dave Abrahams

[joe...@live.com]

Why? And what makes something a "deployment tool?" (I'm not sure I know
what you mean by "deployment").

 

A 'deployment tool' is a tool that does software deployment onto a machine.  In some corporate environments the machines are very closely monitored.  If you had a version of python installed that wasn't patched with the latest security updates it would be flagged.  In the bank that I work in we have controlled software deployment tools.  This may only be an issue for very - so not a huge deal (we can always continue using Boost without it). 

 

Is there a cross-platform user-guide posted that explains how 0install pulls down the dependent packages?

 

 

[Dave Abrahams]

on Tue Feb 05 2013, joewood-AT-live.com wrote:

> Why? And what makes something a "deployment tool?" (I'm not sure I
> know what you mean by "deployment").
>
>
> A 'deployment tool' is a tool that does software deployment onto a
> machine. In some corporate environments the machines are very
> closely monitored. If you had a version of python installed that
> wasn't patched with the latest security updates it would be flagged.
> In the bank that I work in we have controlled software deployment
> tools. This may only be an issue for very - so not a huge deal (we
> can always continue using Boost without it).

Right.

> Is there a cross-platform user-guide posted that explains how
> 0install pulls down the dependent packages?

Not sure what you're after, exactly, but http://0install.net has lots of
documentation.

--
Dave Abrahams

[joe...@live.com]

I actually meant a user-guide for ryppl and Modularized Boost.

 

[Dave Abrahams]

on Wed Feb 06 2013, joewood-AT-live.com wrote:

> I actually meant a user-guide for ryppl and Modularized Boost.

In that case, "not yet."

--
Dave Abrahams