pure Python build system about ontopilot HOT 5 CLOSED

As part of this change, it'd be good to revisit how the build process should be architected. A few key questions:

1. Should builds be out of source or in source? The advantage of out-of-source builds (which we are doing now) is that it minimizes the chances of accidentally and unknowingly messing up output files (i.e., import modules and the ontology). The disadvantage is that users have to manually copy output files into the source tree. In-source builds swap these advantages/disadvantages.

2. Should import modules be imported from the local filesystem using file URIs or should they be imported from a remote source repository? We are currently taking the latter approach, but the obvious downside is that it requires a remote repository and the ontology needs to be configured with the correct URL to download files from the remote. These could be significant barriers to new users. The advantage is that the ontology itself remains small but can still be used by anyone, anywhere, as long as they have Internet access. Note that I need to also add a feature to the software to generate a full ontology with all import entities "sucked in" to the single ontology file (I'll make a separate issue ticket for this). With that feature in place, maybe the advantages of remote vs local import references aren't as big of a deal.

from ontopilot.

1. I am ok with out-of-source builds. I don't think it is all that much work and good instructions should help?

2. Maybe stick with the latter and we can revisit once the software can generate that single ontology file?

from ontopilot.

from ontopilot.

Okay, thanks for the feedback, all. I've finished the initial implementation of a complete, pure Python build system. It does out-of-source builds, and it is driven by a single configuration file to control build details. It should be flexible enough to support import modules with either local filesystem URIs or remote URIs.

from ontopilot.

from ontopilot.