Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by ghaberek (admin) Sep 14, 2015
- 1854 views
I like the name EuDrop Project but I'm not married to it. I think getting the community involved and excited about the project via a naming contest is a great idea. Do we have any volunteers to set up a "Survey Monkey" or something to vote on the name?
We could, but normally we just collect responses in the given thread and tally them up after some time. Works pretty well for our small group.
In short, EuAnyRepo is intended to be for package managers (Apt, Yum, Dnf, ???) what jquery is for javascript. A nice abstraction sitting on top of the different package manager implementations. It's a cool tool but honestly it doesn't solve any Euphoria specific problem. Especially across multiple non-similar platforms.
This sounds like a library and not an application. In fact, it sounds like a really good idea for a library to me. And on supported systems, that library can be used to manage system-wide dependencies as necessary. In fact, I'm not even aware of any library that aims to satisfy this requirement and it doesn't sound terribly difficult to me.
Unfortunately, currently I'm unaware of a software repository for Windows users.
The solution for this is already established: we manage everything ourselves. It sounds dirty, and I don't like it any more than you do, but that's the way Windows is unfortunately. For all of the packages that support Windows, we will have to build and/or provide the binary dependencies and package them somewhere safely, which gets us back to our distributing a DLL discussion from earlier.
There are, of course, some licensing restrictions with that method, so the other option is that we look for the dependencies and then tell the user to go hunt that down and come back later. Hopefully, at least, we can provide a link to where the dependency can be downloaded. I think the key to solving that problem is in how "smart" the dependency data is for each package. Or we just go in blind and let the package handle that after it's installed.
If you buy into the EuDrop Project solution you're probably a Euphoria application developer. You want something like CPAN or Ruby Gems. You want/need tools and libraries that are easy to find, install and use. In fact, if the install and use process can be automated, even better. You realize that you may or may not even have access to install libraries in a global location (like /usr/local/share for example). When you're done writing your software, you don't want to go through some sort of complicated sleuthing exercise to package up your software for your customer.
I agree with this part completely. Simplicity for the end-programmer is key.
If you're a Euphoria Library developer (or a C lib wrapper), you would buy into the EuDrop Project because you don't have time to answer support questions like, "How do I install this coollib thing?", "I included coollib.e but open_dll failed? Where is the dll?", "Thanks for the coollib but it just suddenly stopped working. Can you help?" Additionally, you want to help the community but you don't want to be troubled with infrastructure concerns like hosting, version control, update announcements, etc. You just want to code.
Simplicity is also for the package-builder. Once we define a good package format (which Jeremy at least started on with EuPack), we could probably build a decent GUI for it was well. Programmers are lazy so the whole process has to be heavily automated.
I haven't written anything about this yet but basically, it's like bundler for Ruby. If you buy into this solution, you're an application developer that doesn't see the need for packaging your app at all (except for the code you wrote yourself, of course). You want to provide a list of dependencies and you expect some tool to go get 'em. This might be a pipe dream, but that would be the goal if EuDrop gets stable. In short, this tool would essentially become a EuDrop installer and dependency management tool.
I see where you're going with this but again, this sounds like a function of the package manager. It's really just a matter of having an extra export function to create deb, rpm, or exe installers. Some Windows installers, like NSIS, can be automated quite easily. EuPack is already designed to be modular, so the functionality can be established after it's out as a "new" feature instead of a whole new application.
Another tool that's in my head but not written down yet. It is like rvm. But it's too far away for me to think about yet.
Not sure how I feel about this. I think Git and Mercurial are already fine version control tools. I'm not sure I even agree with rvm existing in the Ruby world, but that's not a world I'm a part of so it doesn't bother me.
-Greg
