On 2013-03-18 13:13 +0100 Andrzej Giniewicz wrote: >Naming of scikits family of packages isn't so obvious. It was also >raised in past, that naming them python-scikits is repeating, because >there is no non-python scikits. scikits- and scikits2- was also >suggested. Lately also names diverged, some packages were using >scikits-* to denote the "scikits repository" later were renamed to >"scikit-*" like in "one of scikits" or dropped it altogether. I'm >hesistant to do renames in AUR because not all AUR helpers handle it >well IIRC. And those packages work correctly, pulling correct >dependencies. I prefer to do rename only once when moving to community, >to cause troubles to users only once, not twice. Especially that it's >directly pacman that takes care for it then, and it does it better by >definition :) > >Why it's not there yet? Because I'm testing two approaches of dealing >with scikits-base package - either as install script or single-file >package. I'm leaning towards the first one, but keeping the scikits-base >in AUR for other packages that depend on it - just making it also >install it by install script. That way I will not have to move "single >file" package into community. I just want to make sure people will have >smooth upgrade. Also had other priorities like finding out why python >bindings for insight toolkit does not build for so long. That's not easy >task because most of those are generated by gcc-xml. I still have to >make two other currently unmaintained and outdated and broken libraries >work. > >I don't know why the rush to rename it right now. Meanwhile, I will >continue my plan of moving them in when they are ready without loosing >my time on rename now, causing extra trouble to users of this package. >Normally, I'd merge one with less votes into one with more votes >(especially that one with less votes is doing compile in package >function), but because it was raised to attention that I'm unwilling to >correct the situation (which was already explained in comments earlier - >nr. 5 from top) - someone might think I did this, because it was my >package, so prefer to stand back, letting someone else decide :P > >So, if someone thinks I should do differently, you are free to merge my >package into the other one. I don't care about having one package more >or less, so don't worry about me :) And I plan to move into community >anyway when scikits stuff is _ready_ - which I can do even if I don't >maintain it in AUR. > >Anyway, if we are at this - we can as well decide about naming of >scikits here and now, once and for all scikits. Because same thing apply >to all scikits in AUR, not only this one or only mine. > >I think we should have scikits-* scikits2-* to keep them consistent. It >will already tell us that package in question is for python or python2, >and that it originates from http://scikits.appspot.com/ - other approach >would be just forgetting common origin for packages and creating long >names like python2-scikit-timeseries or something, based on name from >PyPi - where it is obvious that scikits = scientific python toolkits, so >it's saying python twice. > >A historical note: scikits-* prefix was chosen earlier, because: 1) >there were no support for python 3 yet (and like 90% of scikits still >don't support python 3, just look when scipy got python3 support and >they are scipy extensions), 2) all scikit had it in front also in names, >3) they weren't really separate python packages, but SciPy toolkits, >like extensions to library. It allowed to keep the name short. > >Cheers, >Andrzej.
Blah blah top-posting blah blah. *pushes Andrzej out of the way and merges the package into python-scikits-learn* /jk I think we should maintain the standard of using the language prefix to denote modules. The argument that you give for using "scikits-" does make sense, but it could be used for any library that provides multiple stand-alone language bindings. I would rather see python-foo, haskell-foo, ruby-foo than foo-python, foo-haskell, etc. It maintains consistency and there should be fewer languages than projects. It also indicates very clearly what the package contains. Anything starting with "python2-" is a library for Python 2. foo-python2 could be a library, a set of Python helper scripts, or a Python 2 implementation of something named foo (maybe more?). When you move it to [community], rename it python*- and include scikits*- in the provides array. That should be clear enough for everyone, imo. Regards, Xyne
