Re: CVS commit: wip/py-tortoisehg

Niclas Rosenvik <[email protected]> writes:

> I was thinking like you when I first added tortoisehg to pkgsrc-wip. 
> devel/mercurial is not named devel/py-mercurial. But as it is now I
> think it's better to decide the name when it's imported to
> pkgsrc-current instead of changing it back as this package is almost
> finished.

There are two issues to think about in deciding py- vs not.

One is whether the package is a program that happens to be written in a
language, vs a program that's used as a library by other users of that
language.  So for instance www/trac seems reasonable, but py-twisted.

The other issue is how multiversion support works.  With py-foo, one can
build py26-foo, py27-foo, py33-foo and install all of them.  This can be
useful if some program only uses 27 and some other program only uses 33,
but they end up using some of the same libraries.  In order to be
parallel-installable, a py-foo package also needs to only install files
that are under a versioned directory (lib/pythonX.Y/site-packages,
usually), or things in bin/ that have versioned suffixes.

So a package installing unversioned files in bin somewhat argues for not
using, and installing only versioned files argues strongly for using
py-.

In the case of tortoisehg, it looks like most files are versioned, and
it wouldn't be terribly hard to make the remaining files versioned.  But
I suspect there is no real point, as I don't see why anyone would want
to install both a 27 and 33 version of this at once.    If I'm confused
and there is intent to have parts of the pacakge used programmatically,
that leads to at least keeping open the option of parallel installs.


------------------------------------------------------------------------------