-
Notifications
You must be signed in to change notification settings - Fork 14
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
Drop grpc
/profobuff
dependencies
#551
Comments
I see your point and yes, inconsistency wrt api-go is bad. At the same time, how about dropping api-go? I don't see it solving any problem for us, there are zero other users of api-go, no one needs it except for SDK. You can argue about potential v3, but even that can be handled internally by SDK and other languages (all those 20 languages we support, right?) can do whatever they want with the stable API definitions. |
Dont mind. Maybe even a little "for". But what bothers me is that there is no issue about it (ok, I may be missing it but there is no link to it in the merged PR then), and it is "started" in some weird way with a single method that is still originally generated in |
Yes. We've not touched api-go for some time.
Obviously, @cthulhu-rider just followed the path of least resistance which is to skip api-go. The choice was either to stop him doing that and lose some time refactoring the thing or accept this contribution that solves some problem as is (leaving the question for this issue, notice that we still can refactor, but after it's all integrated).
Everyone hates it.
They were separated to:
Both goals are good on their own, but over time you can notice that in fact:
The ideal world wrt this issue is:
But you know the reality, it doesn't and can't work this way for NeoFS. So we can keep api-go just because we have it and 10 years from now it might become useful in some way or we can forget about it and simplify the process.
Which one? |
I understand and deny this approach for things that are well structured and that a side reader can not expect. No issue about changing our approach (or no link to an issue), no discussion, just done and forgotten. Just like our
No problem, but where is an issue about? How to understand if we are dropping it or not?
Just an example: #36 and #526, ok, it is not even an issue, it is a ready-to-merge suggestion (already done work, harder to complain at review stage, that is what i am talking about) that exactly declines the previous work. We did it more than once. |
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Continues 8a26264 and finalizes deprecation of `neofs-api-go/v2` module in favor of `proto/` packages. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Signed-off-by: Leonard Lyubich <[email protected]>
Continues 8a26264 and finalizes deprecation of `neofs-api-go/v2` module in favor of `proto/` packages. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Signed-off-by: Leonard Lyubich <[email protected]>
Continues 8a26264 and finalizes deprecation of `neofs-api-go/v2` module in favor of `proto/` packages. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Signed-off-by: Leonard Lyubich <[email protected]>
Is your feature request related to a problem? Please describe.
I'm always frustrated when I see them as explicit requirements in
go.mod
. Also, newReplicateObject
RPC is the only RPC that our API repo does not support (generated RPC only, no corresponding funcs in https://github.com/nspcc-dev/neofs-api-go/tree/70b1ffbd81414afce53290d61160b4716be02845/rpc), why?Describe the solution you'd like
Do API-dependent things/implementations in the API repo, and reuse its functionality in SDK.
Describe alternatives you've considered
Nothing. Not sure I would think differently ever. At least -- if we change our perception of the API/SDK, their relations, etc -- we should do it once and with two repos at a time, not one by one.
Additional context
All the thoughts in the thread.
The text was updated successfully, but these errors were encountered: