cvs commit: ports/archivers/hs-zip-archive Makefile distinfo pkg-descr pkg-plist ports/devel/hs-binary Makefile distinfo pkg-descr pkg-plist ports/devel/hs-darcs/files patch-Setup.lhs patch-darcs.cabal ports/devel/hs-darcs Makefile distinfo pkg-d

[Alexey Dokuchaev]

On Thu, May 27, 2010 at 12:32:17PM +0200, Gabor Pali wrote:
> On 2010/5/27 Alexey Dokuchaev had said:
> > both me and Dmitry would appreciate having them renamed back
> 
> You are always referring to the python ports.  So I took a look at them:
> 
> Install executable(s) but prefixed with "py-":
> 
>   [ List of messy Python ports skipped ]

Python ports is an utter mess.  :-(  But it's so many of them, and new
ones are popping so fast (not only ports, but distribution technologies
like eggs, etc.) that I am just scared to get into this shit.

> It is a module but without a "py-" prefix:
>  pybrain
>  pycdf
>  pychm
>  pycodec
>  pycogent
>  pydbx
>  pygts
>  pynids
>  quixote
>  webpy
>  xpyb
> 
> No comment :)

I know, man.  It's that I just do not feel like fighting with python@
cabal at this point, yet we can (right now) do something together so
Haskell ports avoid similar kind of mess.

> Do not get me wrong, I would be happy to revert my changes, but that
> would also mean that some Cabal ports will be also failing your
> criteria after the change.  My problem is that I do not see why only
> darcs, pandoc, porte, xmobar and xmonad should omit the "hs-" prefix?
> Why not Agda, Agda-executable, alex, brainfuck, c2hs, cpphs, haddock,
> happy, hat, HaXml, hdoc, hmake, hoogle, hscolour, idoc, mueval,
> texmath, unlambda, uuagc?

Good question, this is tough choice.  It seems that the problem here is
that while all of the above are technically mainly regular programs or
utilities, some of them are hardly being interesting or useful outside
of Haskell developer playground, others (like Xmonad) can be treated as
completely self-contained and (most importantly) self-valued pieces of
software.

Haskell might not be the most popular tongue of choice right now for
most of userland things, but things might change some day.  Just like
we're not treating C/C++/Java/Perl/C# programs in any special way other
than providing correct runtime environment when they require it.  I
believe we should bear this in mind for Haskell as well, despite the
fact that it's being marginal and still uberly geeky stuff at this
point.

> Let me make it clear that too: ports in the haskell category and
> Haskell Cabal ports are not the same: every Haskell Cabal port is a
> Haskell port (i.e. in the "haskell" category), but not every Haskell
> port is a Haskell Cabal port.  Notable examples: lang/ghc, lang/ohugs,
> lang/nhc98, devel/hs-hat.

I understand.  My point is more generic of that, though: use the right
tools for the right things: e.g. do not abuse port name for encoding
metainformation other than port's name.  In this sence, details of
implementation (associated language/runtime) should be stored (encoded)
somewhere else (inside Makefile/bsd.haskell|cabal.mk, etc.).

> > All package prefixing should be hidden from our users inside
> > makefiles (of ports and supporting infrastructure), not in publicly
> > visible directory names.
> 
> Yes, I understand it.  My intuitions are just getting clear on the
> topic: we want to import another namespace, so we need the "hs-"
> prefix to avoid potential clashes.

It's very unlikely that two ports fall in the same primary category
(ergo, directory) with the same name.  Having two and more ports of the
same name in different categories is OK.  Even in the rare case of name
clash, we have a track record of how to deal with it when it happens.

./danfe