Add package overwrite option #58
Conversation
Codecov Report
@@ Coverage Diff @@
## master #58 +/- ##
==========================================
+ Coverage 90.64% 90.69% +0.05%
==========================================
Files 1 1
Lines 171 172 +1
Branches 10 10
==========================================
+ Hits 155 156 +1
Misses 16 16
Continue to review full report at Codecov.
|
|
The https://framagit.org/upt/upt/merge_requests/4 pull request adds an This allow to do a This pull request adds |
|
@jrjsmrtn this PR is less likely to fly... If there is already a Portfile present, the idea would be to update that one instead of simply overwriting it. We assume that maintainer has "perfected" the Portfile already and we do not necessarily want to replace that with an automatically generated file. As you can imagine such "update" feature is a bit more complex and you can read some discussion about this in the relevant Issue/PR. There is a prototype by @Steap for the update feature here: https://github.com/Steap/upt-macports-update and -to be honest- is waiting for feedback and testing from me... Please feel free to give that a try! |
|
Yes, I saw the effort on update but I think update and overwrite are answers to two different use cases, and are complementary.
I’m trying to package a Ruby-based software for MacPorts. That software has more than 130 _direct_ Gem dependencies. Performing a « upt package —recursive » on the _first_ dependency, bootsnap, generates 32 Portfiles before it breaks.
So, at this time, I’m learning and fixing upt, upt-rubygems and upt-macports, one issue at a time.
Non-backslashed double-quotes in Portfile description fields are fixed in upt-macports. Summary/description fields are fixed in upt, upt-rubygems and upt-macports. Next in line: some Ruby licenses are not recognized and not explicitly reported, my recursive build on bootsnap breaks with an InvalidSpecifier error and I had to add lots of debug messages to even know which dependency was the issue,… :-p
So, in this phase, I don’t need an « upt update ». I need to restart a recursive upt package to regenerate all dependencies’ Portfiles, until I fix all UPT-related issues.
Once all Portfiles are generated, I’ll start to build and install dependencies’ ports, manually tweak them if needed and submit them to MacPorts.
It’s only after that phase that I would (gladly) use a « upt update ».
Does it make sense to you? :-)
G.
… Le 6 déc. 2019 à 03:39, Renee Otten ***@***.***> a écrit :
@jrjsmrtn <https://github.com/jrjsmrtn> this PR is less likely to fly... If there is already a Portfile present, the idea would be to update that one instead of simply overwriting it. We assume that maintainer has "perfected" the Portfile already and we do not necessarily want to replace that with an automatically generated file.
As you can imagine such "update" feature is a bit more complex and you can read some discussion about this in the relevant Issue/PR. There is a prototype by @Steap <https://github.com/Steap> for the update feature here: https://github.com/Steap/upt-macports-update <https://github.com/Steap/upt-macports-update> and -to be honest- is waiting for feedback and testing from me... Please feel free to give that a try!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#58?email_source=notifications&email_token=AABFIPF6C4Q55FIVMOTQXXLQXG3NNA5CNFSM4JVYVBPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGC2STA#issuecomment-562407756>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFIPDSEIBTRHJ5JYFRRIDQXG3NNANCNFSM4JVYVBPA>.
|
|
@jrjsmrtn I see your point and you can certainly make such changes locally, but I am not sure if it will be added to Having said that, as a possible workaround without changing anything in |
Yes, this was in upt-rubygems 0.4 and upt 0.11.
Can you tell me what packages have issues with licenses? My understanding is that people can write whatever they want in the "license" field, making it hard to properly guess what license is used.
I fixed this in upt-rubygems 0.4.1, tell me whether it works for you :) Regarding the "overwrite" feature, it is something I had in mind, and I'm not against adding it at some point, but two things should be kept in mind:
|
|
Regarding the issues with licenses:
|
|
Can you tell me what packages have issues with licenses? My understanding is that people can write whatever they want in the "license" field, making it hard to properly guess what license is used.
I was blocked by some « Apache 2.0 » licenses without a dash and a « Ruby! » with an exclamation point.
Instead of adding more license names to the RubyGemsFrontend._guess_licenses().ruby_to_upt mapping, I added a simple but extensible translation table:
license_transtable = str.maketrans({ " ": "-", "!": None, })
…and used it to translate license names and reduce the number of items in the mapping.
I also added explicit logging of unknown license names in RubyGemsFrontend._guess_licenses().
I’ll submit a PR in the coming days.
my recursive build on bootsnap breaks with an InvalidSpecifier error
I fixed this in upt-rubygems 0.4.1, tell me whether it works for you :)
The following specifiers or versions were breaking:
- « = 0.9.2 » with a single equal (PEP 440 expects a « == » )
- versions with prerelease: « 1.0.0.pre2 »
- « 0.8.7.6 » with four digits
- ...there was a fourth, but I forgot which one :-q
I created a RubyGemsSpecifier class, inheriting from packaging.specifiers.LegacySpecifier and using regexes from rubygems/specifier.rb and rubygems/version.rb.
All patterns are now parsed except for the four-digits version: it's not supported by RubyGemsFrontend._fix_twiddle_waka_expr() nor the semver module. I’m working on it right now and intend to submit a PR later this week.
G.
|
I don't think the twiddle-wakka is supposed to work with anything else than Semver versions, to be honest :-/ |
No worries, but you broke the tests - please fix ;) |
No description provided.