[Haskell-cafe] Re: Announcement: Data.ISO3166_CountryCodes version 0.1

2010-04-25 Thread Jon Fairbairn
John Millikin jmilli...@gmail.com writes:

 Thanks for the library! I'm sure it will be very useful for people
 dealing with internationalized applications / libraries. I have a few
 suggestions, which might make your library easier to use and maintain.

 First, it's very common to include generated files in the
 tarball.

Ah. That would solve the problem of the spurious empty .hsc file.

 This allows users to install the package, without installing 3rd-party
 utilities, or downloading (possibly varying) versions from external
 websites. As your library is currently written, two users who install
 it might end up with dramatically different modules, depending on the
 contents of  http://www.iso.org/iso/iso3166_en_code_lists.txt .

It would take a major global political ructions to make them
/dramatically/ different, but I'm aware of the issue...

 Second, since the module is based on an external data set, a
 date-based version might more appropriate. Version 0.1 means
 nothing, but version 2010.4.24 indicates when the given version was
 generated. Alternatively, you can use a hybrid system to indicate both
 stability and the date -- such as 0.1.20100424.

Something like this is already on my TODO list, but the date
that I want to appear in the version number would be the
last-modified-date of the downloaded code-list. How do I get
that (which the build already puts into a file¹) into the .cabal
file?

 Third, if you'd like your module to be widely used in the Haskell
 community, the BSD3 or MIT license would be more appropriate. For
 technical reasons, the GPL and LGPL are essentially equivalent for
 Haskell packages. For political reasons, choosing the GPL will reduce
 your user market to free-software users. This isn't *necessarily* bad
 -- all of my large projects are GPL'd -- but be aware that your choice
 will heavily limit how many people use your library.

Something close GPL is what I want -- if I'm doing this for
openly and for nothing, I don't see why anyone should build
something on the back of it and make it proprietary without me
having a say. I'd be happy to put a notice somewhere to the
effect that I'm willing to negotiate terms for a separate
license for inclusion in proprietary code, though I'd like to
know the proper way of doing that.

 Fourth, consider storing your code in a version control system (like
 Darcs[1]),

it already is.  

 and publishing it on a website like Patch-Tag[2].

I was waiting for it to be uploaded overnight. If my rsync
system isn't configured to delete it next time, 

   darcs get --lazy http://www.cl.cam.ac.uk/~jf15/ISO3166_CountryCodes/

should get a copy.

[
 trying that without the --lazy just now netted me this:
darcs: bug in darcs!
Another possible bug in URL.waitNextUrl:  curl_multi_perform() - no running 
handles at src/URL.hs:243 compiled Sep 12 2009 12:18:27
I'm unable to check http://darcs.net/maintenance to see if this version is 
supported.
If it is supported, please report this to b...@darcs.net
If possible include the output of 'darcs --exact-version'.

 which isn't encouraging.
]

 This enables people to contribute patches more easily. I've
 already checked it in as a branch[3]

That was a bit premature!

 -- either branch mine, or create your own trunk.

No! :-P

 Finally, instead of using a Makefile to build the library or
 documentation, consider using the cabal-install utility[4]. It's much
 more common for a library to use cabal build or cabal haddock than
 custom make commands, and external tools (such as Hackage) will work
 better.

I'd be grateful for a patch (against my repo) that did that.
I've used make for thirty years, so learning something else
doesn't hold great appeal.


[1] I was going to do something more sophisticated with the
last-modified-date, but in ghc 6.10.4 date and time handling
seems to be a bit of a mess, so I abandoned it.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2009-01-31)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Announcement: Data.ISO3166_CountryCodes version 0.1

2010-04-25 Thread John Millikin
On Sun, Apr 25, 2010 at 01:08, Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:
 John Millikin jmilli...@gmail.com writes:
 This allows users to install the package, without installing 3rd-party
 utilities, or downloading (possibly varying) versions from external
 websites. As your library is currently written, two users who install
 it might end up with dramatically different modules, depending on the
 contents of  http://www.iso.org/iso/iso3166_en_code_lists.txt .

 It would take a major global political ructions to make them
 /dramatically/ different, but I'm aware of the issue...

Well, say some country changes its name, and thus its code. Or some
small country decides to join a larger one. Generated modules will
then have different sets of constructors, but the same version number,
violating the package versioning guidelines.

 Second, since the module is based on an external data set, a
 date-based version might more appropriate. Version 0.1 means
 nothing, but version 2010.4.24 indicates when the given version was
 generated. Alternatively, you can use a hybrid system to indicate both
 stability and the date -- such as 0.1.20100424.

 Something like this is already on my TODO list, but the date
 that I want to appear in the version number would be the
 last-modified-date of the downloaded code-list. How do I get
 that (which the build already puts into a file¹) into the .cabal
 file?

You could generate the .cabal file also, but it would probably just be
easier to check last-modified and set the version number directly.

 Third, if you'd like your module to be widely used in the Haskell
 community, the BSD3 or MIT license would be more appropriate. For
 technical reasons, the GPL and LGPL are essentially equivalent for
 Haskell packages. For political reasons, choosing the GPL will reduce
 your user market to free-software users. This isn't *necessarily* bad
 -- all of my large projects are GPL'd -- but be aware that your choice
 will heavily limit how many people use your library.

 Something close GPL is what I want -- if I'm doing this for
 openly and for nothing, I don't see why anyone should build
 something on the back of it and make it proprietary without me
 having a say. I'd be happy to put a notice somewhere to the
 effect that I'm willing to negotiate terms for a separate
 license for inclusion in proprietary code, though I'd like to
 know the proper way of doing that.

That's fine, but be aware that it'll make your stated goal of I think
anything that uses
country codes should use this datatype! rather difficult to achieve.
Many Haskell developers seem to oppose the GPL -- for example, see the
comments when I released GPL'd bindings to CPython: 
http://www.reddit.com/r/haskell/comments/ajbvb/cpython_haskell_ffi_bindings_to_python/


 Fourth, consider storing your code in a version control system (like
 Darcs[1]),

 it already is.

 and publishing it on a website like Patch-Tag[2].

 I was waiting for it to be uploaded overnight. If my rsync
 system isn't configured to delete it next time,

   darcs get --lazy http://www.cl.cam.ac.uk/~jf15/ISO3166_CountryCodes/

Ah -- there was no source repository stanza in the Cabal file, so I'd
assumed it hadn't been checked into version control yet. I've rebased
my repository upon yours, and attached the Darcs bundle for my changes
to this email.

 Finally, instead of using a Makefile to build the library or
 documentation, consider using the cabal-install utility[4]. It's much
 more common for a library to use cabal build or cabal haddock than
 custom make commands, and external tools (such as Hackage) will work
 better.

 I'd be grateful for a patch (against my repo) that did that.
 I've used make for thirty years, so learning something else
 doesn't hold great appeal.

Cabal doesn't replace Make -- it just defines some basic commands for
compiling, building the documentation, etc. This allows Caballized
packages to be installed on a variety of systems, which might not have
a sane version of Make installed. Usually, this is sufficient to build
all but the most complex of packages (eg, Gtk2Hs).


iso3166_build-style-fixes.patch
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe