David Thomas | 18 Mar 17:26 2014
Picon

Listing native package requirements based on cabal information

Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dan Burton | 18 Mar 17:36 2014
Picon

Re: Listing native package requirements based on cabal information

I have wished for this on multiple occasions. I don't believe such a thing exists as of yet.

-- Dan Burton


On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Thomas | 18 Mar 18:59 2014
Picon

Re: Listing native package requirements based on cabal information

Ok, well, if that's the case I'd like to see about remedying that.  Anyone have any thoughts as to how to best go about this?  I'm not clear on exactly what info lives where, especially across systems.  Entirely manual population would be a (barely) acceptable fallback.


On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I have wished for this on multiple occasions. I don't believe such a thing exists as of yet.

-- Dan Burton


On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Michal Antkiewicz | 18 Mar 19:16 2014
Picon
Picon

Re: Listing native package requirements based on cabal information

Certainly NIX is an interesting approach. It already comes with a large base of dependencies, a format for specifying them. NIX can be installed in any Linux distro and serve as an environment for building packages. That might provide a cross-distribution solution to the native dependency problem.


Michal


On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas <at> gmail.com> wrote:
Ok, well, if that's the case I'd like to see about remedying that.  Anyone have any thoughts as to how to best go about this?  I'm not clear on exactly what info lives where, especially across systems.  Entirely manual population would be a (barely) acceptable fallback.


On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I have wished for this on multiple occasions. I don't believe such a thing exists as of yet.

-- Dan Burton


On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Michal Antkiewicz | 18 Mar 19:29 2014
Picon
Picon

Re: Listing native package requirements based on cabal information

This is not an immediate solution but I can imagine listing NIX packages as dependencies inside a cabal file, then NIX would create a sandbox with these dependencies and cabal would build in that sandbox. The advantages are that you're not messing around with the underlying operating system's packages, NIX handles all dependencies transitively, and everything is specified declaratively. Sounds like a nice GSoC project :-)  You could also do cross GHC version's builds as GHC itself can be sandboxed. Quite intriguing.

Michal


On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <mantkiew <at> gsd.uwaterloo.ca> wrote:
Certainly NIX is an interesting approach. It already comes with a large base of dependencies, a format for specifying them. NIX can be installed in any Linux distro and serve as an environment for building packages. That might provide a cross-distribution solution to the native dependency problem.


Michal



On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas <at> gmail.com> wrote:
Ok, well, if that's the case I'd like to see about remedying that.  Anyone have any thoughts as to how to best go about this?  I'm not clear on exactly what info lives where, especially across systems.  Entirely manual population would be a (barely) acceptable fallback.


On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I have wished for this on multiple occasions. I don't believe such a thing exists as of yet.

-- Dan Burton


On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe





_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Thomas | 18 Mar 19:48 2014
Picon

Re: Listing native package requirements based on cabal information

One option that just occurred to me would be to allow passing a script to cabal that could be passed the extra-libraries (if any), and could install if it knew the relevant OS packages (or NIX packages), or abort with a cleaner error message.

Actually, wrapping ghc might be sufficient (though not ideal).



On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <mantkiew <at> gsd.uwaterloo.ca> wrote:
This is not an immediate solution but I can imagine listing NIX packages as dependencies inside a cabal file, then NIX would create a sandbox with these dependencies and cabal would build in that sandbox. The advantages are that you're not messing around with the underlying operating system's packages, NIX handles all dependencies transitively, and everything is specified declaratively. Sounds like a nice GSoC project :-)  You could also do cross GHC version's builds as GHC itself can be sandboxed. Quite intriguing.

Michal



On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <mantkiew <at> gsd.uwaterloo.ca> wrote:
Certainly NIX is an interesting approach. It already comes with a large base of dependencies, a format for specifying them. NIX can be installed in any Linux distro and serve as an environment for building packages. That might provide a cross-distribution solution to the native dependency problem.


Michal



On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas <at> gmail.com> wrote:
Ok, well, if that's the case I'd like to see about remedying that.  Anyone have any thoughts as to how to best go about this?  I'm not clear on exactly what info lives where, especially across systems.  Entirely manual population would be a (barely) acceptable fallback.


On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I have wished for this on multiple occasions. I don't believe such a thing exists as of yet.

-- Dan Burton


On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe






_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tobias Dammers | 18 Mar 21:47 2014
Picon

Re: Listing native package requirements based on cabal information

Hmm, but then, not all package managers/repositories use the same names
for packages. So even if there were a way to extract the required
libraries from cabal, feeding that information to the package manager
isn't going to be trivial at all. (And frankly, looking at build systems
for other languages, I've never seen anything that does this - even
autotools doesn't really do a lot more than check whether a library is
available).

That said, even if we could just get a list of required libraries out of
cabal, in a somewhat human and machine readable format, that would be a
huge win in itself.

On Tue, Mar 18, 2014 at 11:48:33AM -0700, David Thomas wrote:
> One option that just occurred to me would be to allow passing a script to
> cabal that could be passed the extra-libraries (if any), and could install
> if it knew the relevant OS packages (or NIX packages), or abort with a
> cleaner error message.
> 
> Actually, wrapping ghc might be sufficient (though not ideal).
> 
> 
> 
> On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <
> mantkiew <at> gsd.uwaterloo.ca> wrote:
> 
> > This is not an immediate solution but I can imagine listing NIX packages
> > as dependencies inside a cabal file, then NIX would create a sandbox with
> > these dependencies and cabal would build in that sandbox. The advantages
> > are that you're not messing around with the underlying operating system's
> > packages, NIX handles all dependencies transitively, and everything is
> > specified declaratively. Sounds like a nice GSoC project :-)  You could
> > also do cross GHC version's builds as GHC itself can be sandboxed. Quite
> > intriguing.
> >
> > Michal
> >
> >
> >
> > On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <
> > mantkiew <at> gsd.uwaterloo.ca> wrote:
> >
> >> Certainly NIX is an interesting approach. It already comes with a large
> >> base of dependencies, a format for specifying them. NIX can be installed in
> >> any Linux distro and serve as an environment for building packages. That
> >> might provide a cross-distribution solution to the native dependency
> >> problem.
> >>
> >> See, a nice post by Oliver Charles
> >>
> >> http://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html
> >>
> >> Michal
> >>
> >>
> >>
> >> On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas <at> gmail.com>wrote:
> >>
> >>> Ok, well, if that's the case I'd like to see about remedying that.
> >>> Anyone have any thoughts as to how to best go about this?  I'm not clear on
> >>> exactly what info lives where, especially across systems.  Entirely manual
> >>> population would be a (barely) acceptable fallback.
> >>>
> >>>
> >>> On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email <at> gmail.com>wrote:
> >>>
> >>>> I have wished for this on multiple occasions. I don't believe such a
> >>>> thing exists as of yet.
> >>>>
> >>>> -- Dan Burton
> >>>>
> >>>>
> >>>> On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com
> >>>> > wrote:
> >>>>
> >>>>> Is there a way to extract this?  I'm looking to make it easier for
> >>>>> newcomers to my project to get things building across different linux
> >>>>> distros.
> >>>>>
> >>>>> _______________________________________________
> >>>>> Haskell-Cafe mailing list
> >>>>> Haskell-Cafe <at> haskell.org
> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe <at> haskell.org
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>
> >>>
> >>
> >> <mantkiew <at> gsd.uwaterloo.ca>
> >>
> >
> >
> >

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Rogan Creswick | 18 Mar 21:59 2014
Picon

Re: Listing native package requirements based on cabal information

On Tue, Mar 18, 2014 at 11:48 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
One option that just occurred to me would be to allow passing a script to cabal that could be passed the extra-libraries (if any), and could install if it knew the relevant OS packages (or NIX packages), or abort with a cleaner error message.


You can do this sort of thing in a custom Setup.hs (using build-type: custom).  Depending on the hook you use, you can get access to the cabal file fields there directly.

--Rogan
 
Actually, wrapping ghc might be sufficient (though not ideal).



On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <mantkiew <at> gsd.uwaterloo.ca> wrote:
This is not an immediate solution but I can imagine listing NIX packages as dependencies inside a cabal file, then NIX would create a sandbox with these dependencies and cabal would build in that sandbox. The advantages are that you're not messing around with the underlying operating system's packages, NIX handles all dependencies transitively, and everything is specified declaratively. Sounds like a nice GSoC project :-)  You could also do cross GHC version's builds as GHC itself can be sandboxed. Quite intriguing.

Michal



On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <mantkiew <at> gsd.uwaterloo.ca> wrote:
Certainly NIX is an interesting approach. It already comes with a large base of dependencies, a format for specifying them. NIX can be installed in any Linux distro and serve as an environment for building packages. That might provide a cross-distribution solution to the native dependency problem.


Michal



On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas <at> gmail.com> wrote:
Ok, well, if that's the case I'd like to see about remedying that.  Anyone have any thoughts as to how to best go about this?  I'm not clear on exactly what info lives where, especially across systems.  Entirely manual population would be a (barely) acceptable fallback.


On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I have wished for this on multiple occasions. I don't believe such a thing exists as of yet.

-- Dan Burton


On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe







_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Thomas | 18 Mar 22:11 2014
Picon

Re: Listing native package requirements based on cabal information

Is that cabal file fields for the current project, or cabal file fields for all dependencies?


On Tue, Mar 18, 2014 at 1:59 PM, Rogan Creswick <creswick <at> gmail.com> wrote:
On Tue, Mar 18, 2014 at 11:48 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
One option that just occurred to me would be to allow passing a script to cabal that could be passed the extra-libraries (if any), and could install if it knew the relevant OS packages (or NIX packages), or abort with a cleaner error message.


You can do this sort of thing in a custom Setup.hs (using build-type: custom).  Depending on the hook you use, you can get access to the cabal file fields there directly.

--Rogan
 
Actually, wrapping ghc might be sufficient (though not ideal).



On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <mantkiew <at> gsd.uwaterloo.ca> wrote:
This is not an immediate solution but I can imagine listing NIX packages as dependencies inside a cabal file, then NIX would create a sandbox with these dependencies and cabal would build in that sandbox. The advantages are that you're not messing around with the underlying operating system's packages, NIX handles all dependencies transitively, and everything is specified declaratively. Sounds like a nice GSoC project :-)  You could also do cross GHC version's builds as GHC itself can be sandboxed. Quite intriguing.

Michal



On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <mantkiew <at> gsd.uwaterloo.ca> wrote:
Certainly NIX is an interesting approach. It already comes with a large base of dependencies, a format for specifying them. NIX can be installed in any Linux distro and serve as an environment for building packages. That might provide a cross-distribution solution to the native dependency problem.


Michal



On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas <at> gmail.com> wrote:
Ok, well, if that's the case I'd like to see about remedying that.  Anyone have any thoughts as to how to best go about this?  I'm not clear on exactly what info lives where, especially across systems.  Entirely manual population would be a (barely) acceptable fallback.


On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I have wished for this on multiple occasions. I don't believe such a thing exists as of yet.

-- Dan Burton


On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe







_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Alexander V Vershilov | 19 Mar 13:48 2014
Picon

Re: Listing native package requirements based on cabal information

In Gentoo Linux we use a common ebuild format that allowes to add native dependencies to packages.
To create a ebuild from cabal file we use tool called hackport [1].

This approach allow to bump dependencies when some authors are to lazy to bump them themselves,
even in presence of pull requests, and add compatibility patches. Also it's possible to create a desktop-icons,
additional files, filter test/bench programs that should not be installed into system. Also it supports a dependency
on package flags and profiling.

However this approach doesn't scale on other distros in a easy way, one possibility is to create static
packages using emerge, but this area require some more research.

[1] http://hackage.haskell.org/package/hackport

--
  Alexander


On 18 March 2014 20:26, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alexander
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Thomas | 19 Mar 15:42 2014
Picon

Re: Listing native package requirements based on cabal information

Yeah, it seems that there are a number of potentially good options that are going to vary by distro and situation, which is why I've been thinking "hook to run arbitrary script".  Sufficiently populating the lookup table for that script for any given (Project, Distro) shouldn't be hard, and collecting those we should be able to quickly 1) round the rough edges off of the more common cases without requiring too much manual intervention, and 2) have a reasonable path for the less common cases.


On Wed, Mar 19, 2014 at 5:48 AM, Alexander V Vershilov <alexander.vershilov <at> gmail.com> wrote:
In Gentoo Linux we use a common ebuild format that allowes to add native dependencies to packages.
To create a ebuild from cabal file we use tool called hackport [1].

This approach allow to bump dependencies when some authors are to lazy to bump them themselves,
even in presence of pull requests, and add compatibility patches. Also it's possible to create a desktop-icons,
additional files, filter test/bench programs that should not be installed into system. Also it supports a dependency
on package flags and profiling.

However this approach doesn't scale on other distros in a easy way, one possibility is to create static
packages using emerge, but this area require some more research.

[1] http://hackage.haskell.org/package/hackport

--
  Alexander


On 18 March 2014 20:26, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alexander

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Alexander V Vershilov | 19 Mar 17:02 2014
Picon

Re: Listing native package requirements based on cabal information

I personally not sure about the one right solution, as there are a plenty of different approaches and rules that are applied
system wide, and heavily depend on the underlying package system. Of cause implementation of the new nice features like running
arbitrary script, but I personally don't know of many good examples that can make life much easier without introducing
additional problems.

I'll try to follow up this thread and ready to share our experience and solutions.

--
Alexander




On 19 March 2014 18:42, David Thomas <davidleothomas <at> gmail.com> wrote:
Yeah, it seems that there are a number of potentially good options that are going to vary by distro and situation, which is why I've been thinking "hook to run arbitrary script".  Sufficiently populating the lookup table for that script for any given (Project, Distro) shouldn't be hard, and collecting those we should be able to quickly 1) round the rough edges off of the more common cases without requiring too much manual intervention, and 2) have a reasonable path for the less common cases.


On Wed, Mar 19, 2014 at 5:48 AM, Alexander V Vershilov <alexander.vershilov <at> gmail.com> wrote:
In Gentoo Linux we use a common ebuild format that allowes to add native dependencies to packages.
To create a ebuild from cabal file we use tool called hackport [1].

This approach allow to bump dependencies when some authors are to lazy to bump them themselves,
even in presence of pull requests, and add compatibility patches. Also it's possible to create a desktop-icons,
additional files, filter test/bench programs that should not be installed into system. Also it supports a dependency
on package flags and profiling.

However this approach doesn't scale on other distros in a easy way, one possibility is to create static
packages using emerge, but this area require some more research.

[1] http://hackage.haskell.org/package/hackport

--
  Alexander


On 18 March 2014 20:26, David Thomas <davidleothomas <at> gmail.com> wrote:
Is there a way to extract this?  I'm looking to make it easier for newcomers to my project to get things building across different linux distros.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alexander




--
Alexander
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Simons | 19 Mar 17:09 2014
Picon

Re: Listing native package requirements based on cabal information

Hi David,

 > Is there a way to extract this? I'm looking to make it easier for
 > newcomers to my project to get things building across different linux
 > distros.

what exactly do you mean when by "package requirements"?

Cabal descriptions list the required 3rd party libraries, header files,
and pkgconfig snippets, so there is a lot of information readily
available.

What is missing in your opinion?

Take care,
Peter
Alexander V Vershilov | 19 Mar 17:47 2014
Picon

Re: Listing native package requirements based on cabal information

Some packages require existing executables, e.g. git-annex require lsof.
There were some more examples of packages that doesn't have pkg-config
but require additional programs to be installed.

--
Alexander.


On 19 March 2014 20:09, Peter Simons <simons <at> cryp.to> wrote:
Hi David,

 > Is there a way to extract this? I'm looking to make it easier for
 > newcomers to my project to get things building across different linux
 > distros.

what exactly do you mean when by "package requirements"?

Cabal descriptions list the required 3rd party libraries, header files,
and pkgconfig snippets, so there is a lot of information readily
available.

What is missing in your opinion?

Take care,
Peter

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alexander
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Simons | 19 Mar 18:24 2014
Picon

Re: Listing native package requirements based on cabal information

Hi Alexander,

 > Some packages require existing executables, e.g. git-annex require
 > lsof. There were some more examples of packages that doesn't have
 > pkg-config but require additional programs to be installed.

if the package requires system resources that the Cabal file doesn't
declare, then this is a bug in the Cabal file, no?

Take care,
Peter
Alexander V Vershilov | 19 Mar 18:38 2014
Picon

Re: Listing native package requirements based on cabal information

Such requirement (dependency on executable) can't be covered by the
cabal file (at least with 'simple' build type). It's possible to write custom
setup.hs or use autotools to check such types of dependency.
AFAIK there were other examples of dependencies, that can't be covered
by existing approaches, but I can't show them from the scratch.


--
Alexander


On 19 March 2014 21:24, Peter Simons <simons <at> cryp.to> wrote:
Hi Alexander,

 > Some packages require existing executables, e.g. git-annex require
 > lsof. There were some more examples of packages that doesn't have
 > pkg-config but require additional programs to be installed.

if the package requires system resources that the Cabal file doesn't
declare, then this is a bug in the Cabal file, no?

Take care,
Peter

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alexander
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Simons | 19 Mar 18:55 2014
Picon

Re: Listing native package requirements based on cabal information

Hi Alexander,

 > Such requirement (dependency on executable) can't be covered by the
 > cabal file (at least with 'simple' build type). 

it's true that Cabal lacks a field specifically for such run-time
dependencies, but in the absence of such a stanza using "build-tools" is
a good workaround. The build process can then determine the complete
path of, say, lsof and bake it into the binary. It's a work-around,
though, abusing build-tools in this way is far from ideal.

Take care,
Peter
David Thomas | 19 Mar 17:56 2014
Picon

Re: Listing native package requirements based on cabal information

Well, the most important thing is to make sure people can successfully build things.  Next most important is to minimize the manual intervention required (and the degree to which that manual intervention is spread out through time).

Getting all the necessary 3rd party libraries *for this package and all dependencies* is a good start.  Including, somehow, required utilities would also be worthwhile.  Being able to automate all of that, appropriate to distro and project, would be optimal (but potentially more work than it's worth, depending).


On Wed, Mar 19, 2014 at 9:09 AM, Peter Simons <simons <at> cryp.to> wrote:
Hi David,

 > Is there a way to extract this? I'm looking to make it easier for
 > newcomers to my project to get things building across different linux
 > distros.

what exactly do you mean when by "package requirements"?

Cabal descriptions list the required 3rd party libraries, header files,
and pkgconfig snippets, so there is a lot of information readily
available.

What is missing in your opinion?

Take care,
Peter

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Simons | 19 Mar 18:49 2014
Picon

Re: Listing native package requirements based on cabal information

Hi David,

 >> what exactly do you mean when by "package requirements"?
 >
 > Well, the most important thing is to make sure people can
 > successfully build things. Next most important is to minimize the
 > manual intervention required (and the degree to which that manual
 > intervention is spread out through time).

I am sorry, but I still don't understand what exactly you mean. Could
you please give a specific example of what exactly it is that you want?
Let's use the package "attoparsec" as an example. Could you please write
down the information you consider "package requirements" for that
package?

Take care,
Peter
David Thomas | 19 Mar 19:05 2014
Picon

Re: Listing native package requirements based on cabal information

I don't think attoparsec or any of its dependencies have any native requirements, and some poking around seems to support this, although I don't have any easy way of telling for certain (which is part of what I'm looking for).

On the other hand, something like postgresql-libpq clearly depends on the libpq C library (and possibly other things) as listed in the Extra-Libraries field in its cabal file, *as do anything that require postgresql-libpq* which fact does *not* directly show up in their cabal file.  Walking the tree and pulling that info is a possibility, but it needs to be done after dependency-resolution in case requirements change version to version.


On Wed, Mar 19, 2014 at 10:49 AM, Peter Simons <simons <at> cryp.to> wrote:
Hi David,

 >> what exactly do you mean when by "package requirements"?
 >
 > Well, the most important thing is to make sure people can
 > successfully build things. Next most important is to minimize the
 > manual intervention required (and the degree to which that manual
 > intervention is spread out through time).

I am sorry, but I still don't understand what exactly you mean. Could
you please give a specific example of what exactly it is that you want?
Let's use the package "attoparsec" as an example. Could you please write
down the information you consider "package requirements" for that
package?

Take care,
Peter

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Simons | 22 Mar 09:56 2014
Picon

Re: Listing native package requirements based on cabal information

Hi David,

 > postgresql-libpq clearly depends on the libpq C library (and possibly
 > other things) as listed in the Extra-Libraries field in its cabal
 > file, *as do anything that require postgresql-libpq* which fact does
 > *not* directly show up in their cabal file. Walking the tree and
 > pulling that info is a possibility, but it needs to be done after
 > dependency-resolution in case requirements change version to version.

yes, it's a complicated situation. The information stored in a Cabal
file must be "finalized" before Cabal can use it to install the package.
According to [1], this process depends on the following parameters:

 - Cabal flags chosen by the user,
 - the set of installed (or install-able) packages,
 - the current architecture and operating system,
 - the Haskell compiler used to build the package, and
 - version constraints chosen by the user.

Thus, a given package may depend on an external library 'foo' if you
compile it with GHC 7.6.3, but it depends on 'bar' if you compile it
with GHC 7.4.2, and the same variance occurs recursively in all its
dependencies. It would be nice to know the list of external dependencies
for any given package, but in fact it's not "the list" -- it's many
possible lists, because the outcome depends on the exact environment in
which the package is built.

A rough estimate of these external dependencies is available from Nix,
though. The package postgresql-libpq, for example, has its Hackage home
page at [2]. That page links to the NixOS build information at [3],
which shows the following dependencies:

  acl-2.2.52
  attr-2.4.47
  bash-4.2-p45
  binutils-2.23.1
  coreutils-8.21
  gcc-4.8.2
  gcc-wrapper-4.8.2
  ghc-7.6.3
  glibc-2.18
  gmp-5.1.3
  gnutar-1.27.1
  linux-headers-3.7.1
  ncurses-5.9
  perl-5.16.3
  postgresql-9.2.7
  readline-6.2
  zlib-1.2.8

That list is not be accurate for all environments, but it's a start.

Take care,
Peter

[1] http://hackage.haskell.org/package/Cabal-1.18.1.2/docs/Distribution-PackageDescription-Configuration.html#v:finalizePackageDescription
[2] http://hackage.haskell.org/package/postgresql-libpq
[3] http://hydra.nixos.org/build/9708550#tabs-runtime-deps

Gmane