V3 roadmap and development
-
It would be helpful to have a clearer understanding about development in the context of the v3 roadmap.
In essence, what v3 means is that most current development and patch PRs will be written using a language (PHP) that's going to stop being used in the medium term. While ambitious and desirable, with many advantages, people outside ESF don't seem to have a clear outline of the intended approach or any concept of timescale ("see how it goes and how the resources work out"?). I guess perhaps 1.5 - 3 years, but given the scale of coding and testing, perhaps nobody can tell beyond a very open guess.
That puts voluntary development in a bit of a bind. 2-3 years can also feel like "not a long time". It makes the situation of volunteer-developer enhancements, new packages, new features, and improvements a bit murky - someone might wish to write a non-trivial package, UI-page functionality, or core code enhancement but if it's likely to need recoding in Python in a short while, and their PHP code will get binned for v3, it raises the question of the long-term value of the effort.
Further, at some point, whatever core pfSense there is, will need writing in Python, and bugfixes etc will need submitting in Python rather than PHP, so the existing codebase will need new design, complete new code or some kind of PHP->Python conversion; there may be long-time parallel versions until it's stable and backported to v2, and so on.
I don't know how this aspect is handled, or how it's been handled in other projects that change their main coding/scripting language. I'm sure it's had a lot of thought in-house. It would help to get some insights and ideas, to guide present and new developers who might be thinking about writing new code and patches, but who come across v3 and are apprehensive or uncertain about how their efforts would dovetail with a switch of language a couple of years down the line, and some discussion and clarity on this general area.
In particular, might ESF be able to quickly implement a simple set of Python bindings or "shims", so that the current v2 platform could (1) run Python out of the box as well as PHP, and (2) Python code can call any existing internal PHP functions? I appreciate it's not the same as a native Python approach, but if this were possible sooner rather than later, then pfSense would be able to handle new packages and web pages created in Python, even if it was purely down to "glue" in the background. That would be a nice move for people thinking about new code development, to help developers wishing to transition to Python early (to avoid rewriting of PHP code) could do so very early. It would also act as a simple "shim" to facilitate code transition for existing code to port to Python, even if code would still need updating in the long term from Python-PHP shims/bindings to a native RESTful pfSense API/library as anticipated in the final part of the roadmap.
Extended discussion appreciated, even if ESF doesn't itself have all the answers yet!!
-
It would be helpful to have a clearer understanding about development in the context of the v3 roadmap.
-
Thanks - I read it before posting, but it isn't even slightly on the issue I'm asking about. (One or two posts ask questions in the same ballpark but none of the informed discussion is on this question).
Sorry KOM; to be clear, I'm hoping for a bit of helpful information directly on just one aspect of the roadmap's implications, by ESF persons involved in these plans, which might help to inform new code and enhancement and development creation, since the eventual destination in a "few years" rather than "long distant future" of any new code that volunteer devs write now, is known, it will have to be scrapped or will be definitely incompatible with the future of pfSense, rather than merely requiring incremental updates as usual.
I am happy with the roadmap, but this one area could do with a bit more on how the changeover is tentatively planned to work. This shouldn't be hard, although nobody expects it to be fully known, but it's hard to imagine v3 could be announced without a lot of thought being put into the exact way of managing the code migration path.
In particular if it would help to know if there might be included, a way to let Python be used as well, as soon as possible, on the PHP based v2, as an alternative language (e.g. bindings/shims/"glue" for pfSense PHP functions), so that new code doesn't have to be forced to be written in a language that's heading for the pfSense trashcan in a few years.
-
Duh, sorry. I completely misread your post.
-
While the particular code and implementation of a feature in PHP may change to Python, the logic and process are more important.
Sure there will be a large amount of work involved converting things over but the language is mostly the nuts and bolts of it.
We're more focused on 2.3 at the moment, which has another similar issue. Right now there is a significant amount of work that's happened to convert the GUI to bootstrap which itself is quite a distance away from work in master that has had other, parallel fixes. Merging the two together will be an interesting process.
Right now I wouldn't worry so much about PHP vs Python as much as worrying about the logic and structure/design of the code being sound and easy to follow. Adding even more documentation than usual in the code would also be nice, especially expected inputs/outputs and/or states when defining new functions.
