I’ve been waiting patiently (years honestly) for Xojo to give us a better way to share code between projects and between people. For years this was going to be through plugins written in Xojo but that got canned in favour of Xojo Libraries. These have now been on the roadmap for quite some time but never seem to percolate to release.
Xojo really needs some sort of package manager if it is ever going to grow its user base.
I spend most of my time writing open source code but it is becoming increasingly difficult to do so because I end up having to bundle various modules with different open source projects, duplicating my work and making it confusing for new users to get up and running with my projects.
I’m quite happy to write some sort of open source package manager or web-based package repository for Xojo in my own free time but it requires standardisation. The obvious way to do this is to host Xojo Libraries if they ever become something other than vapourware.
I’ve toyed with creating a package manager for years but have never done so because there hasn’t been a decent way to bundle up code.
Could we as a community get some feedback from Xojo (or @Geoff_Perlman himself) about Xojo Libraries please? My plan is to build a package manager for the community around them once they launch.
Does anyone have any thoughts about this or code reuse in the community in general?
I’ve been pushing for this for a very long time as well (at least 15 years). Both publicly and privately as an MVP. It’s necessary for a variety of reasons, all of which Xojo recognizes. I’m confident we’ll see this soon(ish), but don’t have any details about its implementation or timeframe that I can share.
I would prefer 2,3,4 and 7 over #5 for the R1 any day. Why? Xojo apps look outdated and as I lived until now without “Xojo Libraries”, I can live few months more.
“Xojo Libraries” sounds just like blessed External Encrypted Modules I can do right now.
I was shown how this was done sometime around 2008. I subsequently had to change my business model to no longer distribute encrypted source code. My products at the time ended up on a bunch of piracy sites just from someone decrypting the encrypted demo. I do not trust simple encryption in the IDE because it has to be decrypted at some point in order to be compiled and that means it can be extracted by anyone willing to put in the work.
There’s never just one reason a tool becomes popular / useful but if you look at some of the most successful (such as Python and Ruby which don’t have big name backers) a common feature is a very easy way to share and reuse code. This is something that Xojo is absolutely awful at.
I’m happy to have a crack at helping the community in this area (Microsoft’s Nuget started as a small project by an indie developer) but something like the Libraries functionality is required to be implemented by Xojo Inc before as currently there just isn’t a good foundation to build on.
Agreed. That’s just plain source code with a “import” clause in the language that causes what you are saying. Xojo Libraries is not that, it is the inverse. It is a kind of vault of reusable and unreadable code. It’s more in the reign of plugins than code. Kind of Encrypted Modules. Not a thing we see in the repos that make such languages popular and that people can read the code right from their place in a github repo. What you want is another thing.
As long as you have to pay to share code in plain text format, Xojo won’t become a mainstream tool… No matter what “good reasons” there are for it, that scares new developers away.
Sorry for beeing offtopic, but I just had to get rid of that at this point
But it is easiert to put YEARS of work into the idea of one or very few people that cant think on all the posibilities. When the beta finally arrives with a LOT of bugs and shorcommings “It is too late for changes”
Sure. Even for compiled code. But to make the life of a hacker hard, there’s a way. Encrypted modules could be saved in a unreadable by humans dialect (like many compilers and interpreters did in the past with p-codes) so inspecting the memory after load someone will see just garbage. The “translate back to text” should occur just on demand and using the proper user key, and then, this version will show up. The compiler will read and understand both, the binary blocks version, and the textual blocks version. That’s a fix until someone with lots of time and nothing to do in life tries for months to understand and decode what’s going on and catalog such binary dialect.
As Geoff mentioned we have been making progress on this. We just updated the Roadmap based upon recent progress to give a better idea of the order in which we expect new features to ship.
