[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A unified project root interface

From: Jorgen Schaefer
Subject: A unified project root interface
Date: Sat, 9 Mar 2013 17:44:19 +0100


A growing number of extensions out there deal with "projects" as
opposed to "single files", that is, a collection of files that belong
together in some form or another. The usual way to define a project is
via the "project root", a directory so that all files under that
directory are considered part of "the project".

This is not exactly difficult to write, which has lead to the situation
where pretty much every extension that uses projects defines their own
code to find and set the project root. Examples of this are
find-file-in-project, projectile, elpy, flymake, ropemacs, nose, etc.
Now, if an user wants to use two or more of those extensions together,
she needs to "synchronize" the different ideas of project root manually.
Which gets more complicated the more extensions that define their own
project roots.

It would be really useful if there was a single standard way to define
the project root, so that extensions can just use that standard way
without each and every one of them writing the same code over and over
again. Sadly, as the code is not exactly difficult and so many projects
have already used their own way, it's highly unlikely that a random
third-party library would simply "emerge" as the standard way of doing
things. Which makes me believe the only way to solve this is via a bit
of a top-down decision to include a library in Emacs and declare it as
"the default".

So this is my somewhat verbose request to say "yes, let's do this" and
pick a library to provide the functionality. The library itself doesn't
have to be big at all, in theory a single variable `project-root'
that everyone is encouraged to use would be enough. Adding some
basic functionality to this would be helpful, though. If we keep the
functionality to a minimum, this lets other extensions use it without
being annoyed at the features they drag in.

Suitable libraries exist:

https://github.com/jorgenschaefer/project-el (my own proposal for this
problem, GPLed, happy to assign copyright / should already have.)

https://github.com/nex3/project-el (unsure about the status, it's on
marmalade, though.)

There are probably others.

Does this sound sensible?
Are there other possible approaches?
What's the next step to solve this problem?

        -- Jorgen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]