We've been kicking around some ideas for improvements to build tooling on the Slack channel. Thought I would try to collect some of our thoughts here to elicit feedback more formally:

---

• Improvements to fanr to bring behavior more in-line with main-stream package managers (ie: adding an update option to update installed pods easily; an outdated command to list pods behind latest published version, etc).

---

• Out-of-the-box support for creating build.fan dependencies for pods in remote fanr repos.

---

• Out-of-the-box support for creating build.fan dependencies directly from a hg or git source repo

---

• A new "fan init" tool that can automatically stub new Work/PathEnv environments, pod source trees, etc.

---

• Formalize and publish docs on fan.props and how it works with PathEnv (should this be renamed to a dotfile: .fan?)

---

• Improvements to bootstrap building of Fantom; can we move some of this into fan.props and/or env vars? And move off the old "substitute" scripts (are these even used anymore?)

---

• Add support for automatic building and hosting Nightly builds

---

• Enhancements to sys:Version to follow SemVer and support for pre-release and build meta-data

---

Please add feedback, new ideas, and votes for anything you see here!

Good idea Andy!

---

Feedback

Improvements to fanr i.e. adding an update option to update installed pods

This is a good idea, and its absence is one of the reasons that spurred me to write FPM - which has this feature.

You could just blindly download the latest required pod versions, but you run the risk of dependant pods requiring incompatible (transitive) dependencies.

FPM solves the problem properly and makes certain that all (transitive) dependences are compatible with all the other pod's (transitive) dependences. Trust me, this constraint satisfaction problem is no mean feat. I clocked web projects of mine getting up to 610,397,977,600 dependency permutations.

Out-of-the-box support for ...

I don't understand what you mean by : "creating build.fan dependencies"

A new "fan init" tool that can automatically stub new ...

Again, I'm not really sure what you mean by this. A few years ago I created a (pretty poor) GUI that created a directory structure for new projects and used efan templates to stub out a new build.fan and other related files.

What I learnt is that setting up a project requires a lot of options! But anything that lets people quickly dive into Fantom coding is a good idea.

Formalize and publish docs on fan.props and how it works with PathEnv

I find PathEnv (and the un-documented features) pretty limiting. Again, it's why I wrote FPM and introduced named directory and fanr repositories. FPM encompasses all these PathEnv features and a whole lot more.

Improvements to bootstrap building of Fantom

Building Fantom from source, as per the docs, is woefully complicated. Perhaps I'm not grokking the real issue (as Brian would say) but I really don't understand the necessity behind the whole substitute complexity.

Surely all you need to do is, nav to the project root and run build.fan, optionally specifying an output folder so you don't overwrite your current core pods? Once you've built sys, you can then build the other core pods, no?

So yes, an improvement to the current system would be great!

Enhancements to sys::Version

I guess you're talking about adding alpha / beta / rc flags and other meta. To me, this doesn't seem a good fit for a general purpose Version class. But standardising some properties / values for build meta I'm all for.

As the maintainer of StackHub and Eggbox I already struggle with getting the database to sort and order X.X.X.X versions (I would love it if a Version instance could be shoehorned into a 64 bit Int!) so adding more sort and identity complications I'm not particularly keen on.

---

New Ideas

1. I would love to resurrect the idea of a build.props file as mentioned in #2218 and #2401. This would let scripts bump pod version numbers and build tools / IDEs to easily extract meta.

   The idea is that you would run a build pod and not your build.fan script. The build would actaully look for build.fan and if it exists, run it. If it doesn't exist, then a default empty BuildPod instance would be run.

   The clever bit is that BuildPod (either the default empty one, or the one in build.fan) would look for a build.props file and populate itself with those values should it exist.

   That way, most pods would only need build.props. If you wanted some build scripting, then you still only need the one build.fan file. Or you could have both files. It's all backwards compatible, but really helps out tools and scripts.

2. In general I think the goals should be:
   • make it easy for people to set up Fantom projects
   • make it easy for people to update and build Fantom projects
   • make it easy for people to share Fantom projects / pods

   For the last one, maybe the tools could somehow have tighter integration into Eggbox?

---

Votes

In no order, my favourite ideas are:

• Improvements to bootstrap building of Fantom
• hosting Nightly builds
• A new "fan init" tool
• build.props

Regarding versioning, it'd be nice if the Fantom core pods themselves had tighter, more correct, dependencies.

For example, in Fantom 1.0.71 domkit depends on:

sys        1.0
concurrent 1.0
graphics   1.0
dom        1.0

But this isn't true as it actually requires a version of dom no less than 1.0.70, and I doubt nothing works with sys 1.0.23 anymore!

The Fantom dependencies don't have to be anything complicated, just the current version or later. So for domkit this would be:

sys        1.0.71 - 1.0
concurrent 1.0.71 - 1.0
graphics   1.0.71 - 1.0
dom        1.0.71 - 1.0

I don't understand what you mean by : "creating build.fan dependencies"

Currently the build tools are restricted to looking for pod dependencies on disk via your env chain. Proposal is to enhance this to look for pods in a (1) remote fanr repo and (2) directly from a git/hg repo (which auto download/build to your work env)

A new "fan init" tool that can automatically stub new ...

Again, I'm not really sure what you mean by this.

I think you picked up on this -- but the equivalent of rails new foo type stuff. Just stubbing out directories, skeleton files, etc. Anything you've ever created an IDE macro for -- or copy and pasted a file for.

A few of these seem to have some legs -- so I'll try to break them out as separate "Fantom Enhancement Proposals" flushed out with more details -- and we can discuss them individually.

I've published the first "Fantom Enhacment Proposal" based off this thread -- FEP 1