Closed NicolasKeita closed 7 months ago
Hi. Thanks for contributing this. The update functionality has been on my mind for a while. Unfortunately I don't have too much time to check this, but I'll get to it soon.
Just a first few suggestions:
In a previous attempt I started a while back I added an argument (updatable) to distinguish the frameworks that shouldn't be updatet through umake (e.g. those that have their own updater).
You can find the old version of the update function here: https://github.com/ubuntu/ubuntu-make/pull/506
Just to have a quick look at the defaults and "updatable" argument.
Hi @NicolasKeita
I haven't had much time to look into this, but I'm updating a few things (packaging mainly) on the new_snap
branch.
I need to simplify/remove most of the tests, since they are not maintained.
Did you manage to look at making the update function more modular?
Hi,
I believe that I approached the task with the mindset of adding my code on top of the existing code rather than modifying it to avoid any potential disruptions. If the tests could be revised, I would be more confident in improving my pull request. I believe I can make it more modular :)
Thank you very much for the patience and willingness to look into this.
My proposal would be to split this in two:
add a generic "default" method in frameworks/init.py and frameworks/baseInstaller.py (as in the previous attempt I linked to)
override that method only in frameworks that can update via umake (things like intellij should not because they have their own update system)
add a --list-upgradable in init.py that shows what you did now, so a list of upgradable frameworks.. I would not format them as a table, or anything fancy, trying instead to reuse most of the list method that exists now.
Let me know what you think, and thank you again!
Thanks.
I understood the proposal. Looks good to me. I'll take your pull request (#506) code as base. I should be submitting something in the next few days.
Keep in mind that my old pull request is very old now, so it's not up to date. Just look at it for pointers, or rebase that on master. The first one might be easier.
Let me know if you need help with anything!
The changes I'll be making should not interfere with whatever you do, and at the moment they live in different branches.
the pretty_print function can be easily remove if needed. I filtered only the outdated frameworks (compared to printing every framework installed)
Great!
The only thing missing now is to add a couple of tests. Do you think you could look into that? Specifically a "small" test (you can find them in the tests/small folder), to see if the behaviour is consistent.
I've been looking into the multiple update, and I think I have an idea, but I need to test it out. Basically we should have a way to run umake with multiple frameworks first (for the install as well), then we could reuse that for the update.
Yes, working on it :+1:
Hi,
I couldn't add proper tests. I've faced difficulties with simple tasks, such as initializing a framework object or installing a framework. I've added a placeholder for tests in the meantime. I don't think I am able to perform the tests :disappointed:
I'll look at adding a few tests, just to check that future updates don't break everything, then I'll merge. I might need some time though, since work is taking over at the moment. I'll keep you posted and hopefully this can be merged soon.
Thanks again!
Merging in a separate branch to check and add tests if possible. It'll be then merged in master
add --update option (or -u) to enable comparing the user's version of each framework to the latest version available.
Inspired by an old issue #74 and I wanted to help.
Side nodes:
Feature details: