We have a number of shell wrappers that exist to fix library paths - these are no longer relevant with our configure tools.
We have a large number of perl command line utilities. These are hard to maintain and we don't touch them much. We have invested much more in lib389 with plans to replace all current perl tools with python lib389 tools.
In order to demonstrate this, we need to be able to build a server without the perl tools, to show that the python framework is now in a position to run this standalone.
This adds a flag in defaults.inf that describes if perl is enabled. If perl is disabled, not perl tools are generated or installed.
If the defaults.inf says "perl_enabled = no", then lib389 will now automatically swap to the python 3 based instance installer and removal. This works with the basic test suite, today:
py.test-3 -x -s ds/dirsrvtests/tests/suites/basic 23 passed in 744.57 seconds
This relies on https://pagure.io/lib389/issue/88
Metadata Update from @firstyear: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
<img alt="0001-Ticket-49348-support-perlless-and-wrapperless-instal.patch" src="/389-ds-base/issue/raw/files/fe5ffea4d8cbcd9f0a806aecf39d523684ecefe5660760b152370a949d61de4a-0001-Ticket-49348-support-perlless-and-wrapperless-instal.patch" />
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to review (was: None)
Metadata Update from @firstyear: - Issue assigned to firstyear
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.7.0
I'll give my ack, but porting logconv.pl to python will not be fun.
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to ack (was: review)
We don't have to remove "all perl". We can make an exception for logconv.pl. The main things we want to get rid of is anything with mozldap pl module.
@mreynolds I've put logconv back in for now :)
commit 5b1c8e7 To ssh://git@pagure.io/389-ds-base.git cbe9198..5b1c8e7 master -> master
Metadata Update from @firstyear: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Also what about dbgen.pl? Or repl-monitor.pl?
Perhaps I can finish my ldif-gen.py and use that as a future replacement of dbgen.pl. What's unfortunate is that I had ldif-gen.py fully functional and then my laptop blew up and I lost final changes/enhancements.
I wrote a python dbgen into lib389 already :) It's pretty simple atm, but it tries to emulate dbgen's behaviour.
repl-monitor.pl I would assume would become part of lib389 in the future.
Remember, this isn't "for production yet", this is to help us find places in lib389 where we depend on the pl scripts that we might take away in the future. We'll still keep releasing the pl scripts for some time, but eventually once we are ready and have answered all these questions, then we might take them away and shelve them.
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2407
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Log in to comment on this ticket.