#93 rpm2flatpak: Add an option to initialize from the Flathub manifest
Closed by nphilipp. Opened by otaylor.
modularity/ otaylor/fedmod init-from-flathub  into  master

Download 93.patch

If an application is already packaged on Flathub, allow the user to
initialize the container.yaml from the Flathub manifest by passing

 --flathub=com.example.MyApp

or:

 --flathub=MyApp

to do a search (if the search term isn't unique, the operation will
error out showing a list of matches.)

The tests from flatpak generation are changed to mock out not just the new HTTP requests to flathub/github, but also the use of Koji, since the slowness of actually talking to koji became obvious when running a larger set of tests.

Shouldn't NoSortMapping be a subclass of collections.OrderedDict? AIUI that a dict is iterated in insertion order isn't guaranteed until Python 3.7, right?

flake8 flags these here (with the import-order plugin). I can fix them before applying (I'll rebase onto master anyway, so it's not a biggie).

Same thing about imports being flagged as above, I'll fix it when applying.

I'll probably move these to files beneath tests/files/.

Is there a reason for changing this one to print() but leaving the other log.info() a few lines above in place?

Metadata Update from @nphilipp:
- Request assigned

@otaylor, I'm waiting on an answer to my dict vs. collections.OrderedDict and print() vs. log.info() questions above. Other than these and the changes I mentioned I'd anyway, the PR looks good to me.

Shouldn't NoSortMapping be a subclass of collections.OrderedDict? AIUI that a dict is iterated in insertion order isn't guaranteed until Python 3.7, right?

it's guaranteed for CPython for 3.6, then made an official language feature for 3.7. Unless we want to support older Python 3 than any current Fedora or non-CPython in the near future, dict should be fine. What do you think?

Is there a reason for changing this one to print() but leaving the other log.info() a few lines above in place?

At this point, I can't reconstruct why I changed it to print - I think it was because it wasn't showing up in the pytest output. I'll change it back and push a new version with that and the imports reordered.

what about changing the style - import ordering, with the defaults, test_flatpak_generator.py ends up as:

import logging
import os
import sys
import tempfile
from unittest.mock import Mock, patch
from contextlib import contextmanager
from click.testing import CliRunner
import gi
gi.require_version('Modulemd', '1.0')  # noqa: E402                                                                                                           
from gi.repository import Modulemd
import pytest
import responses
import yaml
from _fedmod.cli import _cli_commands  # noqa: I100     

Which is sort of ridiculous - every 3rd party import is forced into it's own group. While with import_order_style = google, application_import_names = _fedmod in setup.cfg:

from contextlib import contextmanager
import logging
import os
import sys
import tempfile
from unittest.mock import Mock, patch
from click.testing import CliRunner
import gi
gi.require_version('Modulemd', '1.0')  # noqa: E402                                                                                                           
from gi.repository import Modulemd
import pytest
import responses
import yaml
from _fedmod.cli import _cli_commands  # noqa: I100   

Which is much more like I'd arrange the imports.

2 new commits added

  • rpm2flatpak: Add an option to initialize from the Flathub manifest
  • flatpak_generator.py: Use a literal string for finish-args

Shouldn't NoSortMapping be a subclass of collections.OrderedDict? AIUI that a dict is iterated in insertion order isn't guaranteed until Python 3.7, right?

it's guaranteed for CPython for 3.6, then made an official language feature for 3.7. Unless we want to support older Python 3 than any current Fedora or non-CPython in the near future, dict should be fine. What do you think?

You're right.

what about changing the style [...]
Which is sort of ridiculous - every 3rd party import is forced into it's own group. While with import_order_style = google, application_import_names = _fedmod in setup.cfg: [...]
Which is much more like I'd arrange the imports.

Good call. I've changed the configuration and fixed the places which get flagged now, but there are some conflicts now with the PR. Do you want to fix them or should I?

I've fixed the conflicts meanwhile and (as per my comment) also moved the test data to their own files.

Applied in commits abed17b..5f2f6e8

Pull-Request has been closed by nphilipp

Metadata