portability and .cabal files?

[Claus Reinke]

>> yes, that sounds promising. but then i recalled my
>> standard answer when microsoft asks me to let them
>> know the details about how acrobat plugin or ghc or
>> whatever have crashed: it is "no", plain and simple.
>> so, perhaps promising in theory, but not in practice?
>
> Privacy is obviously of vital importance as I noted.

it isn't so much reasonable privacy concerns, but
unreasonable aversion. also, it is easier to say "no"
than to check a large dump of data for privacy issues;-)

but, as Ian says, try it and see what happens.

>> note also that i was talking about .cabal files *specifying*
>> platform-dependencies, and hackage verifying them, not
>> about hackage inferring platform-dependencies from
>> build/failure-reports!-)
>
> Well, you might have access to Windows, Mac, Linux and Solaris boxes but
> I certainly do not. Most other package developers do not either. So they
> cannot specify anything except by feedback from people who do have
> access to those platforms.

ah, neither do i. but i have worked on versions of unix
and i have worked on windows. the kind of platform
dependency that bugs me is the *unnecessary* one,
where people use platform-specific tricks and tools
because they don't know better.

then you can't use some wonderful library W because
you're not on windows, and W uses a windows-specific
dependency instead of a portable one. or you can't
use another wonderful library U because it uses a unix-
specific dependency instead of a portable one, and you
happen to be on windows. and then you find that you
can't build your wonderful application idea, because
the libraries W and U exist that would do the job, but
there is no platform on which both work..

there isn't much anyone can do about the *necessary*
platform dependencies, as someone just has to do the
porting work. but for *unnecessary* platform specifics,
the way to get a portable version is by removing them.
and to do that, you have to know whether something
that works perfectly on your system is or is not in that
subset that will work on many platforms without porting.

and the easiest way to do that if you have to specify
all your dependencies anyway, as in cabal, is if those
dependencies declare their status wrt portability, and
portability gets propagated to dependent packages.

if choosing unix-compat over unix makes the difference
between cabal-check accepting my .cabal file as
portable or limited to unix, i will be more likely to
use unix-compat when i can. same for opengl vs some
windows-specific 3d graphics, etc. etc.

if someone insists on mis-managing path separators
for themselves instead of using a portable package
for that, there is nothing cabal can do about it. that
is when your hackage feedback comes in.

what i'm concerned about are all those simpler
cases that cabal could handle and that would make
life so much easier.. :-)

Ian asks:
|What would go in README that wouldn't go in either
|the Cabal "description" field or the haddock docs?

ideally, anything that can be checked should be in formal
fields, such as build-tools, etc. until recently, many of those
fields didn't even exist, and they aren't widely used yet.

a description is an informal field, but i'd be tempted to
keep it brief and to the point. the README file is the
one i go for to figure out that this is a cabal-32.4,5
package, what that means, and what the how-to-build
instructions of the day are for this kind of package.

other than that, the README file can cover all those
things that do not yet have working .cabal fields, but
over time, more and more information will move to
.cabal (project url, project mailing list, bug tracker,
darcs repo, haddocks, build process, do we need
mingw/autotools or what, has the maintainer retired,
where to send donations, etc..;-)

i'm willing to think of some future .cabal file versioin
as a formalised README, but if i see that version of
cabal for the first time, i still need some kind of friendly
welcome. and until .cabal files do capture everything,
the frequent lack of README files is just frustrating
(recall a thread a while ago where someone was
trying to figure out the various database bindings?).

> Yes, when we thought about this before we all agreed it'd be a nice
> thing. It'd be even nicer if someone had the time to implement it.
>
> Hackage already does some additional checks but letting developers run
> those checks on their own machines and extending the set of checks would
> be great.
>
> Would you like to start by filing your list of suggested checks in a
> trac feature request?

my interest are wide-ranging, but my capacities are limited!-)
currently, cabal is just outside that limit. i occasionally browse
this group via gmane, and i try to direct any cabal-related
suggestions here, but that's about it for now, i'm afraid. please
feel free to record any suggestions you like on your tracker,
for later use by future volunteers.

hope that doesn't make my occasional suggestions unwelcome,
claus

> I think this kind of non-core feature would be better to go in the
> cabal-install tool, though obviously using the Cabal library api.
>
> Duncan
>