Support all aptly commands' parameters/options

[hiddenman]

We use a bit complicated structure of repos/snapshots/etc. with most of the aptly parameters/options.

1. For example, it's important to create mirrors with options like -with-installer -with-udebs to be able to have a fully-working copy of the mirror.
2. For snapshots we use a special "empty" snapshots (described here: https://www.aptly.info/doc/aptly/snapshot/create/) where we pull packages from other snapshots
3. For snapshots these options are often used: -dep-follow-all-variants -no-remove
4. We use filters everywhere (during pull/create and so on)

As far as i can see in the sources code, nothing from the above options are supported so far. Is it possible to add as many parameters/options as possible to each command described in the aptly docs?

Thank you.

[Melkor333]

You're correct, right now it only supports rather basic features.

1. For example, it's important to create mirrors with options like -with-installer -with-udebs to be able to have a fully-working copy of the mirror.

FWIW the mirror can be created manually and will then be used by pyaptly. Pyaptly won't change a created mirror/publish/snapshot (except for archiving), so you can just create the mirror manually and use pyaptly to update it.

2. For snapshots we use a special "empty" snapshots (described here: https://www.aptly.info/doc/aptly/snapshot/create/) where we pull packages from other snapshots
   ...
3. We use filters everywhere (during pull/create and so on)

AFAIU the empty snapshot is only created once, and thus could technically be reused by pyaptly. I never worked with empty snapshots so I'd need an example scenario, but I think that would work. However pull is currently not implemented in pyaptly. filter does exist and I think the code for pull could be implemented very similarly.

3. For snapshots these options are often used: -dep-follow-all-variants -no-remove

This would also require a PR. I think it should be possible to achieve this rather easily by creating a new field like extra-creation-args for snapshots/mirrors. 🤔 (that would also solve the 1. issue)

[hiddenman]

This would also require a PR. I think it should be possible to achieve this rather easily by creating a new field like extra-creation-args for snapshots/mirrors. 🤔 (that would also solve the 1. issue)

I thought this project is again abandoned and switched back to the openapt, added few commits yesterday to support some required options: https://github.com/hiddenman/OpenAPT/commits/feat-snapshot-empty/

Your project looks more promising so i'd like to switch back again, but not sure how and where to add options. openapt is easy in this case.

[Melkor333]

Oh very interesting, didn't know this alternative exists! Interesting that it took exactly the same approach & stack. It looks like both have some advantages and disadvantages.

pyaptly has a few special features like timestamp handling as one of the main intends of the project is to be able to manage "stable" and "unstable" publishes which have the same mirror/base repository but with a gap of certain days (e.g. 7, 14 days) in between.
But for that same reason it's a bit more complicated. OpenAPT looks like a much simpler and straight forward architecture with the models, etc. Pyaptly doesn't really do any verification of the loaded configuration (and thus there's no single place to see what fields an entity has). So you can write in your yaml/toml whatever you want, pyaptly will just use the fields it knows about.
Something that might be improved...

So for example if the mirror creation should have an additional option it can be just added with a short if in the mirror file. Though looking at it I see that both -with-installer -with-udebs are already implemented! (yeah docs for this kinda stuff are a next target)

But for the snapshot options you'd have to start at the function generating a 'create snapshot' command. The function to update a snapshot will be a bit more tricky to update I believe.

The CI will require 100% code coverage so especially the snapshot pull feature will require some additional tests to make sure it works. Create a new snapshot-pull.toml with an example config in the test dir and add a test to the test_snapshot.py.
But you can start a PR and I can help with the testing if you're not familiar with pytest.

[hiddenman]

Oh very interesting, didn't know this alternative exists! Interesting that it took exactly the same approach & stack. It looks like both have some advantages and disadvantages.

The author of the OpenAPT mentioned your project (and the author of the aptly mentioned OpenAPT - that's how i found both of you :)

pyaptly has a few special features like timestamp handling as one of the main intends of the project is to be able to manage "stable" and "unstable" publishes which have the same mirror/base repository but with a gap of certain days (e.g. 7, 14 days) in between.

Actually, they do support this even more feature-rich like: openapt --snapshot-subst "{name}-{now:date:%Y%d%m%H%M%S}_{random:.8s}" --debug --dry-run schema.json

So for example if the mirror creation should have an additional option it can be just added with a short if in the mirror file. Though looking at it I see that both -with-installer -with-udebs are already implemented! (yeah docs for this kinda stuff are a next target)

Great news!

But you can start a PR and I can help with the testing if you're not familiar with pytest.

Will try to take a look, thank you.