-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite installer in Python 3 #3937
Comments
It pains me to say this, but I would suggest changing the title of this issue to "anything but Perl". Kids these days don't use it. 😢 I like Python but we should also consider Javascript, especially because since as of Java 8 there is a Javascript implementation called Nashorn we could use. Java is a hard requirement to run Dataverse. Python is only required if you want to build the docs with Sphinx or if you're hacking on geoconnect, dataverse-client-python, or miniverse. I can't think of a third language I'd suggest. Either Python or Javascript would do. Please don't forget that it's really a Perl installer that calls into a series of Bash scripts. Let us consider if we are rewriting all those Bash scripts as well. If the goal is truly to support Windows better, let's make sure we fully understand how well supported Python or Javascript or whatever is on Windows. I'd suggest that we check with @zhul-pku who opened #3927 and anyone who writes back on the Do you want to develop Dataverse on Windows thread I started on our mailing list. Last thought: If we're re-writing the Dataverse installer not to use Perl, I assume we should also (in a future issue) re-write the TwoRavens installer not to use Perl: https://github.com/IQSS/TwoRavens/blob/master/install.pl |
In the case of vagrant and virtualbox is used for Dataverse development in windows environment, it seems like there is no strong needs to rewrite the perl installer and bash scripts? |
I agree with @zhul-pku here. With vagrant (and the integration of ubuntu in the last windows), I'm not certain there is a need to rewrite anything. There may be a need to clean-up and separate scripts by roles, and config. So we could eventually use the same scripts easily for dev and production. If it needs to be rewritten, I would go with python, because that's what I know best, but I don't think it matters much as long as it is working and doesn't add too many dependencies just to run an installer (which is why I will not vehemently defend porting the installer to anything else than bash and perl). |
We discussed this in sprint planning 10/23. It will be good to revisit this as we are looking at the Glassfish upgrade. Instead of being focused on Python, we may want to make this effort more general and use case focused. I will let more technical folks make this decision. :) |
Massive kudos to @donsizemore for starting the effort 2 years ago. :) |
remaining things to add/check on
|
@scolapasta and I spoke with @donsizemore today about how we'd like to exercise the new Python installer with our "spin up on AWS" scripts so I just created IQSS/dataverse-ansible#139 about this. |
@donsizemore: @pdurbin mentioned you wanted some hooks/options added to the installer to be able to run on a system that has already been set up before. |
… warning from the old installer. (#3937)
@landreev this looks great, but I have another question: Python2 goes EOL on January 1st. Do we want to go ahead and make the jump to Python3? (sorry) I volunteer to take that on if you'd like, now that you've done the heavy lifting. |
@donsizemore I wanted to make it run under Python3, yes. (ideally, under both 2 and 3; but if it has to be Python3 only, should be ok too). |
…e for making a distribution zip bundle. (#3937)
@donsizemore It should be working under Python3 now; while still working under Python2 as well. The reason I wanted backward compatibility with v2, even though it has been officially EOL-ed, was that there should still be many existing systems where Python2 is the default, or the only version, installed. We can discuss going forward whether this backward compatibility is something we want to maintain. |
I have everything checked in and I'll go ahead and make a PR. |
@pdurbin I'm going to open another ticket for the "podname"-based functionality. I replicated what was in the old installer (I think); but it really looks it's currently broken in the old installer - the code that's supposed to set up PostgreSQL appears to be inaccessible, due to faults in the logic. I feel like it's (potentially) useful functionality and I do want to keep it, but I'm not sure if that was the best way to implement it - by relying on environmental variables inside the installer that is. I'm wondering if we'll be better off keeping it out of the installer, but adding a straightforward wrapper shell script, that would check and interpret the environmental variables, and pass them to the installer via the standard command line options and/or .config file entries. Either way I feel it's logical to address this in a separate issue. |
…ental python installer script. (#3937)
@landreev running the script manually, I'm hitting:
should the jar go in /usr/local/glassfish4/glassfish/lib? |
I just checked with @sekmiller (who set up Payara on his laptop this week) and he said yes. |
@donsizemore, that command line, with |
…ded; if you really really have to use v2. - 2.7+ required) (#3937)
This is to support dev environments / installations in Windows.
The text was updated successfully, but these errors were encountered: