1. EuAnyRepo vs EuDrop... what's the difference?
- Posted by xecronix Sep 14, 2015
- 1928 views
Forked from Complete Guide to Using DLLs in OpenEuphoria
Speaking of package mangers for Euphoria. I have like the name euget better. Maybe we should have a vote or a naming contest.
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?
I also think this package manager should include all of the functionality described by EuAnyRepo. Why would these be two separate projects?
Who is your customer?
EuAnyRepo
Honestly EuAnyRepo is meant to solve Linux only problem. The "problem" software developers have when developing software for the Linux problem is whether or not certain 3rd party software (or library) is actually installed on the target system. If it isn't, how do you get it installed for the end user? Is it a yum command, dnf, apt-get, or something else that's required to get some third party software installed for my user?
Unfortunately, currently I'm unaware of a software repository for Windows users. Sadly, the closest thing to a software repository my Windows brethren have is Google. They are forced to scour the net looking for tools and apps that are installed via installers and zip files that may or may not be smart enough to recognize a dependency. Or perhaps they are monolithic in nature? Even if my brethren actually purchase the software they require, there is no reasonable expectation that the software will automatically install 3rd party requirements.
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.
EuDrop
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.
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.
EuBundleIt
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.
EuEnvUs
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.
2. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by ghaberek (admin) Sep 14, 2015
- 1855 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
3. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by xecronix Sep 15, 2015
- 1824 views
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.
Thanks, the idea from this thread The basics are working at this point on Fedora. Maybe a couple more hours of coding and testing this thing should reach beta. And it is a library, not an app.
The solution for this is already established: we manage everything ourselves. ...
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.
You are right, but what we're talking about here is a game changer. And a Super Awesome reason to choose OpenEuphoria over another tool. If we can learn from the several projects that have tried this so far, (Ruby, Python, Perl, PHP) and learn as much as we can from Apt and Yum we could be discussing the killer app for Euphoria right now.
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.
This is the point where I realized where our points of views are in contrast. You are thinking about building a tool that can generate a package like an rpm, deb or exe installer. Right? Im thinking a EuDrop is the Euphoria equivalent of an rpm or deb package.
In debian terms: EuDrop Project about building a package, metadata, and some kick butt tools to make building these things as simple as possible. In other words, this project is about building the Euphoria equivalent of a .deb file.
EuBundleIt If this project gets wings one day, this is about building the apt-get equivalent for EuDrop files.
The end user, developer or otherwise, would most likely interface with the system using something patterned off of synaptic. And like synaptic sits on to of apt-get, Our GUI would sit on top of EuBundleIt.
4. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by ghaberek (admin) Sep 15, 2015
- 1878 views
This is the point where I realized where our points of views are in contrast. You are thinking about building a tool that can generate a package like an rpm, deb or exe installer. Right? Im thinking a EuDrop is the Euphoria equivalent of an rpm or deb package.
In debian terms: EuDrop Project about building a package, metadata, and some kick butt tools to make building these things as simple as possible. In other words, this project is about building the Euphoria equivalent of a .deb file.
EuBundleIt If this project gets wings one day, this is about building the apt-get equivalent for EuDrop files.
The end user, developer or otherwise, would most likely interface with the system using something patterned off of synaptic. And like synaptic sits on to of apt-get, Our GUI would sit on top of EuBundleIt.
No I think we're on point here. I agree that EuDrop should be a package manager for Euphoria - I think that's a great idea and we need it very much.
- I think we need functionality to easily bundle-and-ship applications to the end-user without any dependency on Euphoria or EuDrop or anything else but third-party dependencies.
- I think that functionality should be an extension of EuDrop rather than a discrete product. To me, logically, it just makes sense to extend EuDrop for this.
Here's an example of what I am looking for:
# here is our package configuration
cat coolapp-src/eudrop.info
Title: CoolApp 1.0
Author: Someuser <someuser@example.com>
Package: coolapp-1.0
Depends: coollib-0.2 mylib1-1.4
# create a new package 'coolapp-1.0' from the directory 'coolapp-src'
eudrop --create coolapp-1.0 --source coolapp-src/
Found coolapp-src/eudrop.info
Creating new package... complete.
# push our package upstream to our repository
eudrop --publish coolapp-1.0 --target http://eudrop.openeuphoria.org/myrepo/
Publishing coolapp-1.0 to MyRepo (http://eudrop.openeuphoria.org/myrepo/)
Authentication required
Username: example
Password: ********
Sending data... complete.
# create a new Debian package from 'coolapp-1.0'
eudrop --export coolapp-1.0 --deb coolapp-1.0.deb
# create a new Redhat package from 'coolapp-1.0'
eudrop --export coolapp-1.0 --rpm coolapp-1.0.rpm
# create a new Windows installer from 'coolapp-1.0'
eudrop --export coolapp-1.0 --exe coolapp-1.0.exe
-Greg
5. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by SDPringle Sep 15, 2015
- 1794 views
Although you all probably know this, I will say it anyway. There is a limited tool that copies the included files for a given Euphoria program to some directory for distribution. It is called eudist and it is in the default EUPHORIA package.
Shawn Pringle
6. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by jimcbrown (admin) Sep 15, 2015
- 1802 views
Although you all probably know this, I will say it anyway. There is a limited tool that copies the included files for a given Euphoria program to some directory for distribution. It is called eudist and it is in the default EUPHORIA package.
Shawn Pringle
This doesn't package shared object dependencies (.so files), though. Neither does it serve as a central respository for all dependencies that a given project has.
eudist is a limited tool for a limited purpose (to grab copies of all the source code of an example program so the dev team can run it to track down hard-to-reproduce bugs in the intepreter or translator).
7. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by xecronix Sep 15, 2015
- 1806 views
...
- I think we need functionality to easily bundle-and-ship applications to the end-user without any dependency on Euphoria or EuDrop or anything else but third-party dependencies.
...
... # create a new Debian package from 'coolapp-1.0' eudrop --export coolapp-1.0 --deb coolapp-1.0.deb # create a new Redhat package from 'coolapp-1.0' eudrop --export coolapp-1.0 --rpm coolapp-1.0.rpm # create a new Windows installer from 'coolapp-1.0' eudrop --export coolapp-1.0 --exe coolapp-1.0.exe
-Greg
I haven't gone silent... I'm just thinking. The biggest question that's going through my mind right now is "Why doesn't CPAN, Ruby Gems, pip, or Pear work the way you're describing?"
8. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by ghaberek (admin) Sep 15, 2015
- 1796 views
I haven't gone silent... I'm just thinking. The biggest question that's going through my mind right now is "Why doesn't CPAN, Ruby Gems, pip, or Pear work the way you're describing?"
Good question! The best answer I can think of, is that those languages entirely self-reliant. Anything written in Perl, Ruby, Python, PHP, Java, or .NET requires that the language's runtime be installed on the system in order to run, and that's fine for them. But Euphoria sort of floats this line between a runtime and a compiled language, because we can translate the source and ship the resulting executable without any other runtime. This puts Euphoria at a unique advantage over all of those other languages and gets us closer to the C/C++ territory.
And speaking of C/C++ territory, those don't even have exclusive package management, since they rely entirely on the OS package system. And they have discrete utilities for everything because that world is so diverse and dynamic. You can get away with doing whatever you want however you want, and that freedom can actually be quite overwhelming.
-Greg
9. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by xecronix Sep 16, 2015
- 1769 views
Greg, I'm hoping to team up with you on this project. It seems like we have a lot of the same or similar ideas. There is defiantly overlap to say the least. This is the only sticky part for me.
...
- I think we need functionality to easily bundle-and-ship applications to the end-user without any dependency on Euphoria or EuDrop or anything else but third-party dependencies. ...
... # create a new Debian package from 'coolapp-1.0' eudrop --export coolapp-1.0 --deb coolapp-1.0.deb # create a new Redhat package from 'coolapp-1.0' eudrop --export coolapp-1.0 --rpm coolapp-1.0.rpm # create a new Windows installer from 'coolapp-1.0' eudrop --export coolapp-1.0 --exe coolapp-1.0.exe
-Greg
And speaking of C/C++ territory, those don't even have exclusive package management, since they rely entirely on the OS package system. And they have discrete utilities for everything because that world is so diverse and dynamic. You can get away with doing whatever you want however you want, and that freedom can actually be quite overwhelming.
-Greg
I'm not so sure about this statement. I think an argument can be made that the autoconf tools are C/CPP close equivalent. However, Windows doesn't support the concept. For example, on Linux when you download a project source you expect that you can then run:
./configure && make && sudo make install
If all goes well, and you have all the right dlls and includes on your system you'll have installed your new software. dlls would end up in your LDPATH somewhere. Header files would end up in /usr/include, probably. And your executable will have ended up in your /usr/bin/ most likely. There are many examples of exceptions to this generalization OpenEuphoria being one of them.
On Windows, there is no such concept. Though it's close. If a developer follows Windows guide lines, dlls would end up in Windows/system32 (or whatever the equivalent is these days... IDK). And most everything else ends up in c:\program files (or whatever the equivalent is these days)
On Windows, header file locations are addressed by the compiler software. So, Visual Studios expects that by default header files are stored in a particular location. Pelles C expects the files to be somewhere else. This concept extends to OpenEuphoria on both Linux and Windows. Why do I say this? Because like Visual Studios and Pelles C, OpenEuphoria expects expects things like include files to be installed somewhere relative to it's install directory by default. Additionally, all 3 mentioned tools allow overrides based on command line switches.
My two points that I'm trying to make with all that I said above are these:
- There is a system in place and you as the C/CPP developer are free to ignore it. But, if you do, you'll make it more difficult for end users to use your software and for other developers to team up with you.
- Even C/CPP developers have some dependencies on autoconf and make if they want to play nice with other developers and end users. (End users because someone is building packages like rpm and deb based on project configuration)
Good question! The best answer I can think of, is that those languages entirely self-reliant.
Good answer. And if I were to list out the numerous reasons why I think the other projects try to build language specific tools to solve this problem, your answer would make the list.
At first glance, it looks easy to build deb or rpm automatically with a single tool. But I don't think it is. RPM packages for one system may or may not be compatible with another system. Same is true for deb packages. In fact if you think about it, what do you think is the number one reason for hundreds of Linux distros anyway? I don't really know for sure but if I were to guess, some guy or team didn't like the packages on any of the current distros and decided to make their own Linux. They didn't like what the packages were called, or they didn't like where they were installed or whatever. Trying to create a generic RPM or deb is possible. But then would you actually be following the guidelines of the distro? Maybe not.
So, if you're not following the guidelines then why bother? I think this is the question that the other teams might have been trying to answer when they came up with their solution. And perhaps for them, they decided that it would be better to create a system for their community that worked particularly great for their community.
The engineers that came up with these solutions were not at all limited to using Perl, PHP, Python or Ruby. These guys I'm sure are at least as diverse in technology as the team is here on OpenEuphoria. But a solution that works identically across all systems will require some pre-installled software of some kind. If something has to be installed to make a cross platform installer solution work, might as well make that something Euphoria.
10. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by xecronix Sep 16, 2015
- 1761 views
But a solution that works identically across all systems will require some pre-installled software of some kind. If something has to be installed to make a cross platform installer solution work, might as well make that something Euphoria
Actually... I'm wrong about this point. I'll update the wiki page to reflect the accommodation of the no dependency requirement.
11. Re: EuAnyRepo vs EuDrop... what's the difference?
- Posted by xecronix Sep 16, 2015
- 1753 views
Maybe something like EuShip?
