Over the years I’ve tinkered with several other programming languages but I’ve always found myself gravitating back to Xojo. One of the other languages that I’ve experimented the most with is C#. There’s a lot to like about C# and .NET in general but that’s for another topic. One thing that C# (and Microsoft’s Visual Studio in particular) is its package manager - NuGet. This is now fully integrated with Visual Studio - you can search its repositories for libraries (think Xojo modules) that do almost anything and can install them and any dependencies with a single click.
Well that sounds good but what’re the chances of the happening in the Xojo ecosystem? I think we’ll all agree that Xojo Inc have a lot on their engineering plates at the moment with Android and Web 2.0 but this is a solution that could (at least initially) be implemented by the community. That’s exactly what happened with NuGet. It started out as an open source specification for how libraries describe themselves and any dependencies they require and the team (single guy?) behind it wrote a command line tool to fetch the required packages and incorporate them into a Visual Studio project. That seems doable for Xojo. So long as the project is in XML or Project format then I don’t see a technical reason why a motivated individual (or group) couldn’t do something similar.
Imagine - how cool would it be if you needed to add unit testing to your project and a quick search for Kem Tekinay’s XojoUnit suite could be downloaded and integrated? Need to add a physics engine - sure, just search for my ImpulseEngine.
There’s a huge amount of Xojo third party open source code out there on the internet but most of it is scattered over various GitHub profiles, personal blogs or has even been lost to time as Xojo developers have moved on.
I think this could be a real innovation to help Xojo developers - after all, it’s not that there is a shortage of great code out there, it’s just too hard to find.
a) You need a robust ecosystem of external modules.
b) You need a really secure solution.
c) You need maintainers for the modules. A repository doesn’t give you a benefit if you are using 2019r3 and the module was last updated in 2015.
hmmm … while there could be hurdles I dont see it as impossible
simple - no; the IDE will make some things a pain in the butt to do
doable ? in some fashion I would think so
Hi Beatrix, really nice to see you here. Let me address your points:
There are loads of open source modules and custom classes out there on the net for Xojo. It’s clear that there are plenty of Xojo developers who are happy to share their work with others. Granted, many of these are “as-is, with no warranty” and none of them share a common format but there is certainly supply.
In terms of being robust, I think we could setup a central repository server to host interesting modules we find so they don’t disappear into the ether (Always Busy Corner I’m looking at you!). We could make it easy for developers to submit modules to the repository should they choose. If a module doesn’t get updated or has bugs then so be it - that’s the case with all open source software: NuGet, Ruby Gems, Python PIP modules are no different.
How so? Are you concerned that they’d be a security issue in the code you download? That’s no different than the current state of affairs where you might come across a module on a developer’s GitHub account. All I’m proposing about the package manager is that it presents an archive of useful code to you - it would be added to your Xojo project as normal so you would be free to view and edit the code as normal. If you found an issue with the module, we’d have to have a nice way for you to report it back to the community so the module could be updated or removed.
Whilst that would be nice I don’t think it’s compulsory. I think the first step is to make existing open source code more accessible and visible to the Xojo community by providing a central place to search for it. We could design the packaging system to have a manifest that stipulates the last version the module was tested with (for example). Take a look at this screenshot from NuGet in Visual Studio:
You can see that in the red box is displayed information about this particular package. We could have it so it displays whether or not it compiles with API 2.0, etc. Also, just because we would be providing a central place to discover code, doesn’t mean that the original author isn’t going to get credit - the package manager could clearly display links to the project’s website, the developers website, etc.
Really depends on how we tried to do this
If you download a “component” - we’ll leave this loosely defined for now - then you need to get the IDE to import it if you want this to be really automatic
That can be a challenge since the IDE while slighly scriptable on macOS has less such capability on Windows & Linux
This can make the level of integrations something that may be less than the goal you initially set out
If we put binary projects to one side (one has to imagine that they’re a non-starter), would a simple implementation be just to have a small app where you search for packages that downloads and copies the files of the components into the project folder of a particular Xojo project, saves the open Xojo project and relaunches the IDE? Would an IDE relaunch be necessary or would the navigator pick up newly added files?
if the package manager simply alters the existing xojo project as it exists on disk, the causes the IDE to reload that would work
BUT - you stand to lose changes that have no been saved
And when the IDE does ask you to save, you stand to lose what the package manager just inserted into the project manifest as the manifest is rewritten
At worst the manager would have to
trigger the IDE to “save” any unsaved changes
rewrite the manifest with the package added to it
now get the IDE to reload the project it just altered which, because you saved it, can not be done with a “Revert to Saved”
on macOS because of how applications work where they can be open with no document step 3 could be a “close project. open project” - this action could have issues on windows or linux as you could cause a complete restart with all the associated start up time of loading plugins etc
Well you did say the idea would make some things a pain in the butt to do…
It certainly is sounding feasible though which is encouraging. I suppose ultimately the hope would be that it could be implemented in a less than ideal manner (although providing a solid central repository) and Xojo Inc could simply poach it and integrate it more nicely in the Xojo.
I think first and foremost, to work with a hypothetical Xojo package manager, third party developers would have to adhere to a certain way of structuring the code of their library. This would mean that the package manager would only work from this point forwards without refactoring. Trying to create a package manager that can handle everything from a single module “package” (e.g. MarkdownKit which is a single module containing methods and classes) to a complex “control” like the excellent CustomEditField which is multiple modules and classes (some internal to modules, others standalone) would be too difficult.
I would have thought a good first step would be to support third party libraries that are either a single module (which may or may not contain classes and submodules) or a collection or modules which can be specified in a “package spec file”.
