Skip to content
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

Draft pull request: Add Vapor and Linux support #642

Closed
wants to merge 38 commits into from

Conversation

ronaldmannak
Copy link
Collaborator

Quick and dirty fix to get web3swift to work on Linux and Vapor. Comments how to improve the code are welcome.

Known issues:

@JeneaVranceanu
Copy link
Collaborator

It looks like tests failed for a commit where CI for Ubuntu wasn't ready yet.

@yaroslavyaroslav Could you please approve the workflow for Ubuntu for the latest commit? According to what I saw all tests should pass.

@yaroslavyaroslav yaroslavyaroslav marked this pull request as ready for review November 4, 2022 05:17
@yaroslavyaroslav
Copy link
Collaborator

yaroslavyaroslav commented Nov 4, 2022

@JeneaVranceanu i’m unable to do so, like literally no such button. Seems like your lint PR broke this one and it required to be rebased from develop once more.

It was really necessary although, since there was a mess (and there still is) within code, so code was haunted for such linting rather sooner or later.

@janndriessen
Copy link
Collaborator

@JeneaVranceanu i’m unable to do so, like literally no such button. Seems like your lint PR broke this one and it required to be rebased from develop once more.

It was really necessary although, since there was a mess (and there still is) within code, so code was haunted for such linting rather sooner or later.

yea I had to rebase mine as well. that could be one of the issues.

@yaroslavyaroslav yaroslavyaroslav added the enhancement New feature or request label Nov 11, 2022
@JeneaVranceanu JeneaVranceanu added the linux Issue or PR mainly about issue/feature/question on Linux OS label Nov 13, 2022
@yaroslavyaroslav
Copy link
Collaborator

yaroslavyaroslav commented Nov 14, 2022

One things is matters for me is to avoid #if os(Linux) as much as it possible. So I'd wish to take some time to overthought it, how it could be designed properly. For now I see only one place where such case is really required: The one that overrides getData() async. So I need to look very closely into each case where it is used and ensure that there's none options to avoid them. Means this one could take a while.

@ronaldmannak
Copy link
Collaborator Author

@yaroslavyaroslav I'd love to avoid that as well, but I'm not sure what you mean that all except one are 'not really required'. How are you proposing to solve to the other cases?

Copy link
Collaborator

@yaroslavyaroslav yaroslavyaroslav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely agree with making conditional imports in several files where some URLSession related methods implemented. There's two for now.

On other hand I don't agree with usage of conditional imports that is happens to handle URLSession call within any internal method: this one could be extracted into separate function that in turn could be placed file where such conditional import provided already.

I don't p agree with any #if conditions within any method implementation as well. Those cases could be handled by either separate type extensions, that is used @available(Linux) clause, or separate type stored in separate file which availability manages in Package.swift.

Also I consider it important to state that mixing platform related code is leading to a huge codebase mess almost instantly, so I'd encourage any person to avoid it at all costs.

Comment on lines +339 to +342
#if os(Linux)
// return Data(URandom().bytes(count: length))
return try? Data.random(length: length)
#else
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like it's good time to change this sepc256k implementation to those that bitcoin maintains, that did @JeneaVranceanu proposed in the past. I'd bet it's cross platform.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be cross-platform as it's written in C but it's not a solution here as the code you are commenting on is our custom extension function and it's just the question of how to get secure random bytes on Linux.

I'd not complicate this PR with the secp256k1 update.

Comment on lines +8 to +10
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this proposal I see that URL doesn't included within FoundationNetwork, is it necessary here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me double check if this one is necessary

Comment on lines +45 to +48
#if os(Linux)
// return Data(URandom().bytes(count: length))
return try? Data.random(length: length)
#else
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is necessary, why btw? But if it is, it's better to implement it in a way as backward capability implemented above.

Means implement exact same methods as existed one, but marked it with @available(obsolete) on all Apple platforms.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is SecRandomCopyBytes isn't available on Linux. I was trying to avoid spinning up a new process and use dev/random, but now believe it might be inevitable.

// Created by Ronald Mannak on 10/29/22.
//

import Foundation
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we importing libc here?

Comment on lines +9 to 10
#if !os(Linux)
import WebKit
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess this file should be excluded from the sources on the Linux platform in a manner that it is now for macOS one. Means it should be ignored in Package.swift.

Comment on lines +6 to +8
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif
Copy link
Collaborator

@yaroslavyaroslav yaroslavyaroslav Nov 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this one should be refactored to not use URLSession in it (it was a rough one implementation within 3.0.0 release, so it's could be changed).

Comment on lines +7 to +9
#if !os(Linux)
import CoreImage
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've got to investigate what the hell happening here, and why ERC spec file required CoreImage as an import?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's for the creation of the QR code, which is convenient to have on iOS and macOS I assume.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, so we really could consider just to crop this file for a Linux platform until we figured out how we could implement it properly.

@yaroslavyaroslav
Copy link
Collaborator

Worth to say that I'm considering that adding new platform support is a big step further, in the meaning, that it possibly wouldn't gets easy, and could require some preparation to provide it into the prod.

I'd propose to create separate long living branch linux where all the work could be done appropriately with no rush, and that could be reached by any folks who need linux so hard that are considering to use pre released version of the lib.

Also that'll allow to update that branch with latest lib releases if any and any fixes, we can even introduce some pre-release tagging there.

I mean this one is a really good start for linux branch, but as for me it's a far away from production ready so far.

@yaroslavyaroslav
Copy link
Collaborator

yaroslavyaroslav commented Nov 15, 2022

But anyway, maybe I'm overreacting here, and other folks has another look onto this @JeneaVranceanu @janndriessen @mloit

@janndriessen janndriessen marked this pull request as draft November 17, 2022 14:09
@yaroslavyaroslav yaroslavyaroslav changed the base branch from develop to linux-support November 17, 2022 14:45
@yaroslavyaroslav
Copy link
Collaborator

I've changed the base of that PR to new created external branch for Linux

@yaroslavyaroslav
Copy link
Collaborator

yaroslavyaroslav commented Nov 24, 2022

@ronaldmannak And now you have push rights to that branch.

This exact PR also could be merged in it.

@JeneaVranceanu
Copy link
Collaborator

@ronaldmannak Hello!
I'll look into this PR once again today. It would be great to merge it into development.
Wanted to ask if you have any updates that you'd like to push to this branch?

@JeneaVranceanu
Copy link
Collaborator

@ronaldmannak I'm closing this PR in favour of #810 as it has all your commits. I wasn't able to update this PR so I had to focus on a new one.
If you have any updates please base them on MoonfishApp/develop or linux-support branches of this repository.

@yaroslavyaroslav All comments mentioned here will be addressed in the #810

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request linux Issue or PR mainly about issue/feature/question on Linux OS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants