[Scons-dev] The Contrib Repository. [was Adding support for Visual Studio Code workspace generation]

[Russel Winder]

On Sun, 2016-11-27 at 12:42 -0800, Bill Deegan wrote:
> Andrew,
> 
> If it's interesting to you, go ahead and work on it!
> There's an index of community supported builders in the wiki. Feel
> free to
> add your work there (https://bitbucket.org/scons/scons/wiki/ToolsInde
> x).
> Or if you like add it to here: https://bitbucket.org/scons/scons-cont
> rib
> 

This raises the issue of whether we should be thinking about active
curation of the Contrib repository, and how to manage it.

Currently having the individual repository per tool, it is easy to
clone the repositories to ~/.scons/site_scons/site_tools or
<project>/site_scons/site_tools and things just work.  hg/git/bzr as
management tools have many positive aspects, and a few negative ones,
over any using pip.

The Contrib repository appears to have to be installed, presumably
using setuptools or pip. This is not yet a package on PyPI, so it
cannot be pip-ed in via download, you have to have the hg clone. And
then there is the issue that anyone using a platform with package
management should never use pip into the package managed area – always
use pip --user.

Also it seems that each individual tool in Contrib has to have a
separate installation record, which will be a management nightmare
without automation.

So this raises a number of issues.

1. What is the purpose, aim, and goal of the Contrib repository?
2. Is it intended as the place where things will be migrated out of the
SCons core distribution?
3. Should it deploy into the running SCons installation or to a
site_scons/site_tools?
4. Is it just for tools?
5. Should SCons support not-tool add-ins better?
6. What is the process for adding things to Contrib?
7. What is the mechanism for removing things from Contrib?
8. Is it feasible to move the C, C++, Fortran, D stuff out of the core
without a total rewrite of the core?
9. Is anyone thinking about how to do C++ builds with SCons in the
presence of package managers such as Conan.

In a sense I feel a bit of a fraud contributing here just now. Apart
from LaTeX builds, and a few small pet projects, I am hardly using
SCons just now. CLion (*) required CMake as the build tool, so most of
the C and C++ projects I workl on use CMake, and the other C and C++
projects I am associated with use Autotools :-( or are moving to Meson.
D, Rust, Go, all have their own build systems, and the  Kotlin, Groovy,
Ceylon, Scala, Clojure, Java, i.e. JVM-based languages either use
Gradle (or Maven) or have their own build frameworks (sbt, lein,…)

Having said this, having shoved hard at the Python 3 compatibility for
SCons and the tools as repositories with a central index, I feel a
responsibility to see these through to some form of conclusion, even
though I am using SCons less and less.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20161128/6045e2bb/attachment.pgp>