Re: The Contrib Repository. [was Adding support for Visual Studio Code workspace generation]

Russel Winder <[email protected]> Mon, 28 Nov 2016 09:36:53 +0000
Newsgroups	gmane.comp.programming.tools.scons.devel
Message-ID	<[email protected]>
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:[email protected]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [email protected]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
signature.asc (application/pgp-signature, 833 B)