+1 There is already precedence in the repo for python for other purposes. The only caveat I would include is to be sure you include backward compatibility for python 2.x for the next year or so until it goes EOL.
Jonathan G On 11/9/18, 5:23 PM, "Rawlin Peters" <[email protected]> wrote: Hey TC devs, As we eliminate the need for Traffic Ops Perl, it will no longer really make sense for the db/admin.pl script to be Perl as it is today. This is because it depends on the Perl modules that are installed via Carton for running Traffic Ops Perl. However, it's mostly just a Perl wrapper around shell commands except for a YAML Perl module and the `reverse_schema` command which uses the DBIx Perl module to generate the ORM schema for Traffic Ops Perl (i.e. you've added a new DB table/column and need to get the ORM files updated to use it). Without TO-Perl, there's no need for the `reverse_schema` command in db/admin.pl and its dependency on the Perl DBIx module. At that point db/admin.pl is just a Perl script that parses some YAML and shells out commands. Part of the problem with TO-Perl is that there are a bunch of random non-API Perl scripts that basically assume all the modules in the cpanfile are installed in the environment, even though a lot of those dependencies are probably only required for the Perl TO API or UI. So unless we go through all those Perl dependencies to eliminate everything we don't really need once the Perl TO API and UI are completely removed, we'll continue to have a handful of Perl scripts like db/admin.pl that still require downloading and installing the full set of TO Perl dependencies. On fresh installs, running Carton to install these dependencies can take nearly half an hour. I'm working on adding tests for the DB upgrade/downgrade process which I'd like to run automatically on PR submissions, but it really only needs the db/admin.pl script out of TO which assumes the entire set of Perl TO dependencies even though it mostly just shells out to `goose up` and `goose down`. I'd like the test to emulate an actual TO environment as closely as possible to match what would actually happen in a production DB upgrade/downgrade. Right now I'm reusing the Traffic-Ops-Perl Docker image from cdn-in-a-box, but ideally I'd like to port db/admin.pl into Python to give it its own set of dependencies (just a YAML package) and not require the full set of TO Perl dependencies. Then I can spin up a much lighter-weight container with just the TO Python packages rather than setting up a separate cpanfile with just the Perl packages needed for db/admin.pl. +1/-1 for adding Python as a dependency of Traffic Ops for porting scripts like db/admin.pl? -Rawlin
