FlightGear package manager: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
(layout; cat)
Line 1: Line 1:
{{Stub}}
{{Stub}}
{{Package Management}}
{{Package Management}}


{{WIP}}
{{WIP}}


{{cquote
{{cquote
Line 81: Line 82:
   }}
   }}
}}
}}
[[Category:Core development projects]]

Revision as of 01:58, 7 March 2015

This article is a stub. You can help the wiki by expanding it.


WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.
Cquote1.png Well, if we make a manual catalog.xml from the current fgdata/Aircraft (which I have parts of a script to do), and we treat the current aircraft zip URLs as canonical, that is possible with current code right now - since it can do the zip download + extraction to a directory of our choice. We could throw an (ugly) PUI UI around that, and then if someone with more talent than me wants to Canvas-GUI-ify it, that will be great.

I will attempt to get a prototype version of this working tonight / tomorrow. I don’t promise to produce anything usable but as you say, anything would be an improvement.
— James Turner (2014-05-30). Re: [Flightgear-devel] select/download aircraft.
Cquote2.png
Cquote1.png Thomas Geymayer and I are working on it, I am not sure where’s he go to with the UI, the backend pieces are mostly there but will need some intensive testing. There is a #define flag you can toggle (in HTTPClient.cxx) to enable the code including the Nasal API; it will download / refresh a catalog, which is generated by the scripts I committed to fgmeta a week ago. Then you can access the package system from pkg.root in the Nasal console, using the API defined at the bottom of HTTPClient.cxx.

If you are crazy enough to enable this code, and run it, be aware it downloads zips, unpacks them, makes calls to unlink files, renames directories, and so on. I would recommend some caution, and especially, don’t run it as root - while developing it I had it extract a few zips to ‘/‘ or worse due to screwed up path logic.

Equally, I would welcome a code review of the code in simgear/package/Install.cxx to check any security issues or dangerous behaviour. The code /tries/ to be ‘safe’ - extract zip to a temporary folder, and uses rename/unlink to atomically update if the zip extraction succeeds. But it’s only had one pair of eyes on it so far.
— James Turner (2014-06-10). Re: [Flightgear-devel] select/download aircraft.
Cquote2.png


Cquote1.png the goal here is to almost get rid of a centralised aircraft repo anyway, and have a decentralised development system with the only central point being the aircraft package manager for end users. Then 99% of people never care where the aircraft is stored while it’s developed.
Cquote2.png
Cquote1.png The goal is that no one except people working on an individual aircraft should care where it’s developed at all (on GitHub, in a private SVN repo, stored as sheets of paper in a filing cabinet). SCM systems are not distribution/release systems, we’ve simply been using them in that fashion by accident.
— James Turner (2015-03-06). Re: [Flightgear-devel] FGData size reduction.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png If you wish to dig into the package system, and create some tooling so it’s easy to publish releases from a Git repo to a web-host, please do. The current script is in fgmeta; see ‘create_catalog.py’ which runs over FGData of course, but you can imagine something similar for any SCM store containing several aircraft. There’s additional features that can be added of course, such as support for ‘beta’ or ‘testing’ versions of aircraft, being able to exist alongside stable versions. That would require some C++ hacking on the client side but pretty straightforward stuff I think.
— James Turner (2015-03-06). Re: [Flightgear-devel] FGData size reduction.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Historically, FlightGear tends to re-invent the wheel more often than not unfortunately - but adopting a package/plugin framework would definitely make sense. While we can certainly proceed without one, the outcome is likely to be hugely incompatible and cause a ton of chaos - once you think about just how many features were/are developed as "addons", some more attention should be given to such considerations and requirements (bombable, advanced weather, fgcamera, tutorials etc)
— Hooray (Sat Nov 22). Re: How to add sort of addon?  .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The question is how far we'd want to go with something like this - because at some point, it would make more sense to adopt an existing package management system that is multi-platform and open source (e.g. pacm or miniconda). Otherwise, most of the building blocks for a simple package manager are already available to Nasal, i.e. http bindings and SGPath wrappers to download stuff into $FG_HOME and install stuff there. Even though it would probably make sense to also expose zlib (i.e. for extracting compressed archives). Metadata for package names, dependencies, URLs and version/description info could be provided via existing PropertyList XML files. So there's very little missing to pull this off, and a simple prototype for an existing addon, like FGCamera, should be fairly straightforward to build - it's mainly a matter of integrating existing technologies properly, and exposing them first to scripting space.

But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync.

And particularly pacm is looking pretty good actually.
However, historically, the project tends to "re-invent the wheel" more often than not ...


— Hooray (Thu Aug 14). Re: Alternative camera control.
(powered by Instant-Cquotes)
Cquote2.png