-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #18: add support for deprecated-versions #49
Fix #18: add support for deprecated-versions #49
Conversation
@yvan-sraka I am aware it's a draft but I left some comments to put you in the right direction. Ping me if you have questions! |
9a86e4c
to
6031717
Compare
Thank you for your early review and comments, it definitely helped me! I just pushed my last week's work, it seems to works as expected against my local manual experiments. Are there some test scenarios I can run this PR against to be confident it's fully working as intended, if not, I could try to add them in another PR! I left |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the core changes, we can check the webpages when the core logic is working.
427ee3e
to
5b62981
Compare
Also perhaps this could be the PR that finally introduces some tests? :D |
5ea8ae8
to
4e349c6
Compare
I reworked the core logic thanks to your feedbacks :) |
I started something simple here #50, the idea would be to write something End-2-End by spawning some HTTP server and then run Cabal against it! Is it the kind of tests you had in mind? |
4e349c6
to
4974e12
Compare
Cabal can run against a file repository, so no need for the server. We could do this, but we could also do simpler things like just making some assertions about the content of the index tarball. Or we could try and use some logic from cabal the library to test if the repository looks right without having to run cabal separately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic is still not correct. I had a go myself and, to be fair, the end result looks a bit convoluted:
We start from packagesVersions
which is roughtly [(PackageId, [(Timestamp, Bool)])]
The deprecated versions are per package so we need to group per package name:
~ [(PackageName, [(PackageVersion, [(Timestamp, Bool)])])]
Then, for each package, we need to take all version deprecation changes, sort them by the timestamp, accumulate them into version ranges:
- Flatten on the deprecation changes ~
[(PackageName, [(Timestamp, PackageVersion, Bool)])]
- Accumulate into version ranges ~
[(PackageName, [(Timestamp, VersionRange)])]
Then, we flatten on the timestamp to spit out each index entry.
- Flatten on timestamp ~
[(PackageName, Timestamp, VersionRange)]
I'll paste my code soon, just need to double check.
PS: There's a fair bit of whitespace change. I don't mind it di-per-se but I'd avoid changing whitespace back and forth. FWIW I use the default formatting with hls (which I think is ormolu but I am not sure).
Something like this let extraEntries =
foldMap
( \packageGroup ->
let pn = pkgName $ pkgId $ NE.head packageGroup
deprecationChanges =
sortOn fst $
foldMap
( \PreparedPackageVersion {pkgId = PackageIdentifier {pkgVersion}, pkgVersionDeprecationChanges} ->
map
( second $
\deprecated ->
if deprecated
then intersectVersionRanges (notThisVersion pkgVersion)
else unionVersionRanges (thisVersion pkgVersion)
)
pkgVersionDeprecationChanges
)
packageGroup
effectiveRanges =
NE.tail $
NE.scanl
(\(_, range) (ts, change) -> (ts, simplifyVersionRange $ change range))
(0, anyVersion)
deprecationChanges
in map
( \(ts, effectiveRange) ->
mkTarEntry (BL.pack $ show effectiveRange) (IndexPkgPrefs pn) ts
)
effectiveRanges
)
(NE.groupWith (pkgName . pkgId) packageVersions) It's only left ot make it readable (and to test it) 😂 |
Co-authored-by: Andrea Bedini <[email protected]>
2e27d6b
to
7da6927
Compare
Weird, I use |
@michaelpj I think this is now in a decent shape. Would you have time to give it another look and a test? |
getExtraEntries :: [PreparedPackageVersion] -> [Tar.Entry] | ||
getExtraEntries packageVersions = | ||
let groupedPackageVersions = NE.groupWith (pkgName . pkgId) packageVersions | ||
generateEntriesForGroup packageGroup = map createTarEntry effectiveRanges |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally appreciate type signatures for more complex functions like this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the signatures and more comments.
|
||
-- Apply a given change (`VersionRange -> VersionRange`) to a `VersionRange` and | ||
-- return the simplified the result with a new timestamp. | ||
applyChangeToRange :: (UTCTime, VersionRange) -> (UTCTime, VersionRange -> VersionRange) -> (UTCTime, VersionRange) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
almost the applicative instance for Timestamped
😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's
newtype Timestamped a = Timestamped (Maybe (Last UTCTime), a)
deriving (Show, Eq, Ord)
deriving (Functor, Applicative) via Ap ((,) (Maybe (Last UTCTime)))
app/Foliage/Pages.hs
Outdated
-- original cabal file | ||
AllPackageVersionsPageEntryPackage | ||
{ allPackageVersionsPageEntryPkgId = pkgId, | ||
allPackageVersionsPageEntryTimestamp = fromMaybe currentTime pkgTimestamp, | ||
allPackageVersionsPageEntryTimestampPosix = utcTimeToPOSIXSeconds (fromMaybe currentTime pkgTimestamp), | ||
allPackageVersionsPageEntrySource = pkgVersionSource | ||
allPackageVersionsPageEntrySource = pkgVersionSource, | ||
-- FIXME: this weirdly seems to not work (display a `Deprecated` badge on all package version page) ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
going to fix it now or not? It potentially suggests a bug in how we're deciding if things are deprecated or not, which seems serious...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if only we had tests :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I forgot about that note. It was put there before lots of changes so I wonder it's still true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a missing </td>
, it's fixed now.
Should I perhaps rebase this PR on top of #51? |
Likely disabled by accident.
- Add label also to revisions - Resize the label on package versions page
@yvan-sraka @michaelpj I want to merge this soon. Please have a last look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't tested (I assume you have), but looks fine!
I tested what I could. I guess we should just press this green button and see what happens 😂 |
This is a modest work in progress Pull-Request, I wanted to double-check with you in first place if I effectively edited the right parts of the codebase?