diff options
| -rw-r--r-- | paper.tex | 18 |
1 files changed, 9 insertions, 9 deletions
@@ -397,20 +397,20 @@ Very good feedback on the simplicity of using Make has been received from early \subsection{Project configuration} \label{sec:projectconfigure} -Maneage orchestrates the building of its necessary software in the same language that it orchestrates the analysis: Make (see Section \ref{sec:usingmake}). -Therefore, a researcher already using Maneage for their high-level analysis easily understands, and can customize the software environment too, without delving into the intricacies of third-party tools. -Most existing tools reviewed in Section \ref{sec:principles} use package managers like Conda to maintain the software environment, but since Conda itself is written in Python, it does not fulfill our completeness principle \ref{principle:complete}. -Highly-robust solutions like Nix and GNU Guix do exist, but they require root permissions which is also problematic for this principle. +Maneage organizes both the building of its software and the analysis pipeline using Make (see Section \ref{sec:usingmake}). +Thus, a researcher using Maneage for high-level analysis easily understands and can customize the software environment without needing to learn third-party tools. +The existing tools listed in Section \ref{sec:principles} mostly use package managers like Conda to maintain the software environment, but Conda itself is written in Python, contrary to our completeness principle \ref{principle:complete}. +Highly-robust solutions like Nix and GNU Guix exist, but these require root permissions, contrary to principle P1.3. -Project configuration (building the software environment) is managed by the files under \inlinecode{reproduce\-/soft\-ware} of Maneage's source, see Figure \ref{fig:files}. +Project configuration (building the software environment) is managed by the files under \inlinecode{reproduce\-/soft\-ware} of Maneage's source (see Fig.~\ref{fig:files}). At the start of project configuration, Maneage needs a top-level directory to build itself on the host (software and analysis). -We call this the ``build directory'' and it must not be under the source directory (see \ref{principle:modularity}). +We call this the ``build directory'' and it must not be located inside the source directory (see \ref{principle:modularity}). No other location on the running OS will be affected by the project, including the source directory. -Two other local directories can optionally be specified by the project when inputs (\ref{definition:input}) are present locally: 1) software tarball directory and 2) input data directory. -Sections \ref{sec:buildsoftware} and \ref{sec:softwarecitation} elaborate more on the building of the required software and the important problem of software citation. +Two other local directories can optionally be specified by the project when inputs (\ref{definition:input}) are present locally: 1) a software tarball directory and 2) an input data directory. +Sections \ref{sec:buildsoftware} and \ref{sec:softwarecitation} detail the building of the required software and the important issue of software citation. A Maneage project can be configured in a container or virtual machine to facilitate moving the project without rebuilding everything from source. -However, such binary blobs are optional outputs of Maneage, they are not its primary storage/archival format. +However, such binary blobs are optional. They are not Maneage's primary storage/archival format. \subsubsection{Verifying and building necessary software from source} \label{sec:buildsoftware} |