Well, it turned out that it's already the case, there was just a racket hole... T1638

@zack @douardda @moranegg Latest adaptations packaged and deployed

The deposit cli is not though.

Plug on master

Rebase on latest master

Plug on master

• Remove unnecessary leftover check on no longer existing url fields

Fix typo and flake8 error

I'm going to try and run it, but am a bit blocked with swh-deposit command................

the metadata file linuxperf-v4.3.1.27.metadata.xml (as per the parsing error xml.parsers.expat.ExpatError: syntax error: line 1, column 49 implies something badly formatted).

Rebase on latest master

Plug to master

• utils: Enforce necessary setup for deposit and associated client

This revision was not accepted when it landed; it landed in state Needs Review.Wed, Apr 17, 10:52

Fix in-between interactive rebase

Rebase on latest master

Rebase on latest master

Plug on master branch

Rebase on dedicated branch

I have badly dealt with this issue.

In D1411#30788, @ardumont wrote:

@douardda @olasd I have changed the migration to run the 4 steps
mentioned \m/

To do that, i iterated with git (amending) and reused the data files
generated through multiple calls to make db-prepare (wrapper on
swh.deposit.manage makemigrations)...

In the end, I checked the following command to see the sql generated
(in between last version with the old type and the new one):

python3 -m swh.deposit.manage sqlmigrate deposit 0015_depositrequest_typemigration
BEGIN;
--
-- Add field type2 to depositrequest
--
ALTER TABLE "deposit_request" ADD COLUMN "type2" varchar(8) NULL;
--
-- MIGRATION NOW PERFORMS OPERATION THAT CANNOT BE WRITTEN AS SQL:
-- Raw Python operation
--
--
-- Remove field type from depositrequest
--
SET CONSTRAINTS "deposit_request_type_id_e9882b75_fk_deposit_request_type_id" IMMEDIATE; ALTER TABLE "deposit_request" DROP CONSTRAINT "deposit_request_type_id_e9882b75_fk_deposit_request_type_id";
ALTER TABLE "deposit_request" DROP COLUMN "type_id" CASCADE;
--
-- Rename field type2 on depositrequest to type
--
ALTER TABLE "deposit_request" RENAME COLUMN "type2" TO "type";
--
-- Delete model DepositRequestType
--
DROP TABLE "deposit_request_type" CASCADE;
COMMIT;

Expectedly, that does not show the data migration part which happens
through python. But that indeed mentions the migration step ;)

Update test docstring to match the reality of the test

Related D1419

ardumont: could you do a paste with the generated xml? I can't seem to be able to run the client today (i'll have more time to reconstruct that part locally tomorrow)

• utils: Make parsing date result in a reasonable date

• Refactor: Extract date utils manipulation function into utils module

• tests: Factorize metadata xml duplication to explicit tested date

• deposit_read: Refactor to clarify intents and docstring

I would add/change the date formats in tests (because we can recieve dates in different styles)
and/or test only the _parse_date and compute_date functions.
Here some examples:

<date type="whenSubmitted">2018-02-27 10:45:10</date>
<date type="whenWritten">2012</date>
<date type="whenModified">2018-06-11 17:02:02</date>
<date type="whenReleased">2018-03-20 13:09:08</date>
<date type="whenProduced">2012</date>
<date type="whenEndEmbargoed">2018-02-27</date>

Plug diff on master

Make it work using tempfile.mkstemp instead of NamedTemporaryFile

• deposit_status: Simplify the deposit status computation