Re: [REPORT] Board report for Apache Avro Apr 2020
FWIW, nice summary, good to see Avro going strong... On Wed, Apr 8, 2020 at 10:12 PM Sean Busbey wrote: > > Hi folks! > > Here's the report for the quarter I submitted. Let me know if there are any > last minute changes y'all would like to see. > > > ## Description: > Apache Avro is a data serialization system with a compact binary format. It is > used for storing and transporting schema driven serialized data. The unique > features of Avro include automatic schema resolution - when the reader's > expected schema is different from the actual schema with which the data was > serialized the data is automatically adapted to meet reader's requirements. > > ## Issues: > The project currently has no issues that require board attention. > > ## Membership Data: > Apache Avro was founded 2010-04-20 (10 years ago) > There are currently 33 committers and 23 PMC members in this project. > The Committer-to-PMC ratio is roughly 3:2. > > Community changes, past quarter: > - No new PMC members. Last addition was Nándor Kollár on 2019-08-29. > - No new committers. Last addition was Ryan Skraba on 2019-12-12. > > ## Project Activity: > Apache Avro 1.9.2 was released on 2020-02-12. This release included some new > experimental features that try to improve performance[1]. > > Work has continued to update both build tools, language versions, third party > dependencies, and ease of integration in preparation for a new major release > currently planned for May 2020, version 1.10.0. > > The previously reported need to document and update how the project versions > releases came up for discussion again but no action has been taken yet. > > ## Numbers > For those who prefer metrics: > > Mailing Lists: > - dev@avro.apache.org had 1034 emails (24% increase) > - u...@avro.apache.org had 91 emails (15% increase) > > JIRA: > - 115 issues opened (42% increase) > - 76 issues closed (7% increase) > > GitHub: > - 88 PRs open (9% increase) > - 68 PRs closed (7% decrease) > > Code Repository: > - 122 commits in the past quarter (67% increase) > - 25 code contributors in the past quarter (39% increase) > > ## Community Health: > Community health is doing well at drawing in contributions. The PMC still > needs to work to recognize contributors through committership. Current focus > is on working towards releases. > > [1]: user facing details about these experimental additions is available: > https://s.apache.org/6pcpo
[jira] [Commented] (AVRO-2793) Schema compatibilty should consider fullname of records
[
https://issues.apache.org/jira/browse/AVRO-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17080419#comment-17080419
]
Jurgis Pods commented on AVRO-2793:
---
I can certainly do that. However, upon further inspection, there seems to be a
test case that explicitly checks that schemas containing records with different
namespaces are compatible. There must be a reason someone put that test there,
doesn't it?
[https://github.com/apache/avro/blob/master/lang/java/avro/src/test/java/org/apache/avro/TestSchemaCompatibility.java#L250]
> Schema compatibilty should consider fullname of records
> ---
>
> Key: AVRO-2793
> URL: https://issues.apache.org/jira/browse/AVRO-2793
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.9.2
>Reporter: Jurgis Pods
>Priority: Major
>
> Consider the following example:
> {code:java}
> Schema writerSchema = Schema.createRecord("fieldname", null, "namespace1",
> false, Collections.emptyList());
> Schema readerSchema = Schema.createRecord("fieldname", null, "namespace2",
> false, Collections.emptyList());
> // compat.getType() should be SchemaCompatibilityType.INCOMPATIBLE, but is
> actually SchemaCompatibilityType.COMPATIBLE
> SchemaPairCompatibility compat =
> SchemaCompatibility.checkReaderWriterCompatibility(readerSchema,
> writerSchema2){code}
> I would expect the validation to yield an incompatible result, as records
> should have identical fullnames.
> This issue is similar to AVRO-2322, but vice versa: Here the namespace
> differs, not the record name.
> The root cause seems to be in
> [SchemaCompatibility::schemaNameEquals|https://github.com/apache/avro/blob/master/lang/java/avro/src/main/java/org/apache/avro/SchemaCompatibility.java#L97],
> where getName() is used instead of getFullName().
> Is there any reason not to be strict here and use the fullname for
> validation? We ran into severe problems after changing a record's namespace
> in a newer schema version. The Avro schema compatibiltiy check ran through
> fine, so we deployed with confidence. However, the change then caused
> problems both for Confluent's Kafka S3 Connector as well as for Amazon Athena
> when reading data produced by the new schema.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AVRO-2792) Fix C# logical type tests to work in other timezones than UTC
[
https://issues.apache.org/jira/browse/AVRO-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17080548#comment-17080548
]
Andy Le commented on AVRO-2792:
---
[~sekikn]
> Avro's timestamp logical type has a long value that represents the difference
> from the unix epoch (1 Jan 1970 00:00:00 UTC) and it doesn't have timezone
> information.
Do you think that we need to update the Spec to have timezone information?
> Fix C# logical type tests to work in other timezones than UTC
> -
>
> Key: AVRO-2792
> URL: https://issues.apache.org/jira/browse/AVRO-2792
> Project: Apache Avro
> Issue Type: Bug
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Major
>
> I ran the C# unit tests outside of a container and got the following error.
> This is because my machine's timezone is JST (UTC+9).
> {code}
> $ cd lang/csharp
> $ ./build.sh test
> (snip)
> X TestLogical_TimestampMicrosecond() [22ms]
> Error Message:
> Expected: 1990-01-01 14:15:30
> But was: 1990-01-01 05:15:30
> Stack Trace:
> at Avro.Test.Generic.GenericTests.test[T](String s, T value) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 38
>at Avro.Test.Generic.GenericTests.TestLogical_TimestampMicrosecond() in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 139
> X TestLogical_TimestampMillisecond() [< 1ms]
> Error Message:
> Expected: 1990-01-01 14:15:30
> But was: 1990-01-01 05:15:30
> Stack Trace:
> at Avro.Test.Generic.GenericTests.test[T](String s, T value) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 38
>at Avro.Test.Generic.GenericTests.TestLogical_TimestampMillisecond() in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 133
> X TestTimestampMicrosecond("01/01/2019 14:20:00","01/01/2019 14:20:00Z") [<
> 1ms]
> Error Message:
> Expected: 2019-01-01 14:20:00
> But was: 2019-01-01 05:20:00
> Stack Trace:
> at Avro.Test.LogicalTypeTests.TestTimestampMicrosecond(String s, String
> e) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Util/LogicalTypeTests.cs:line
> 143
> X TestTimestampMillisecond("01/01/2019 14:20:00","01/01/2019 14:20:00Z") [<
> 1ms]
> Error Message:
> Expected: 2019-01-01 14:20:00
> But was: 2019-01-01 05:20:00
> Stack Trace:
> at Avro.Test.LogicalTypeTests.TestTimestampMillisecond(String s, String
> e) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Util/LogicalTypeTests.cs:line
> 119
> Test Run Failed.
> Total tests: 584
> Passed: 580
> Failed: 4
> Total time: 2.3598 Seconds
> {code}
> [As the specification
> says|https://avro.apache.org/docs/current/spec.html#Timestamp+%28millisecond+precision%29],
> Avro's timestamp logical type has a long value that represents the
> difference from the unix epoch (1 Jan 1970 00:00:00 UTC) and it doesn't have
> timezone information. So when deserializing it, it's returned as a C#
> DateTime object with UTC.
> Therefore, if the input string lacks timezone information, we should assume
> it represents UTC datetime in these test cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (AVRO-2795) GenericData.EnumSymbol() does not validate the provided schema as actually an enum or that the literal is legal
radai rosenblatt created AVRO-2795:
--
Summary: GenericData.EnumSymbol() does not validate the provided
schema as actually an enum or that the literal is legal
Key: AVRO-2795
URL: https://issues.apache.org/jira/browse/AVRO-2795
Project: Apache Avro
Issue Type: Bug
Reporter: radai rosenblatt
the following code does not throw any exceptions.
{code:java}
Schema notAnEnum = Schema.parse("{\"type\": \"record\", \"name\": \"NotEnum\",
\"fields\": [{ \"name\": \"f\", \"type\": \"string\"}]}");
GenericData.EnumSymbol oopsie = new GenericData.EnumSymbol(notAnEnum, "illegal
literal");{code}
however, later - when the symbol instance is actually used, things explode.
seems to be we can validate the Schema argument is of type enum and that the
literal is a legal name?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AVRO-2775) JacksonUtils: exception when calling toJsonNode()
[
https://issues.apache.org/jira/browse/AVRO-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17080845#comment-17080845
]
Doug Cutting commented on AVRO-2775:
Perhaps it's a non-issue. Today attempts to pass an arbitrary Java class to
this method would fail. An application could depend on this. So changing it
is marginally incompatible. Is it incompatible enough to worry about?
> JacksonUtils: exception when calling toJsonNode()
> --
>
> Key: AVRO-2775
> URL: https://issues.apache.org/jira/browse/AVRO-2775
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.9.2
>Reporter: Andy Le
>Priority: Major
>
> I've got a simple test as followed
> {code:java}
> public class TestJacksonUtils {
> public static class Age{
> public int value = 9;
> }
> @Test
> public void testToJson(){
> Map kv = new HashMap<>();
> kv.put("age", 9);
> JsonNode node1 = JacksonUtils.toJsonNode(kv); // -> This is OK
> Object obj = new Age();
> JsonNode node2 = JacksonUtils.toJsonNode(obj); // -> This will trigger an
> exception
> }
> }
> {code}
> When I ran the test:
> {noformat}
> org.apache.avro.AvroRuntimeException: Unknown datum class: class
> org.apache.avro.util.internal.TestJacksonUtils$Age
> at
> org.apache.avro.util.internal.JacksonUtils.toJson(JacksonUtils.java:87)
> at
> org.apache.avro.util.internal.JacksonUtils.toJsonNode(JacksonUtils.java:48)
> at
> org.apache.avro.util.internal.TestJacksonUtils.testToJson(TestJacksonUtils.java:20)
> {noformat}
> I've read the code & tests for JacksonUtils. Instead of raising exceptions at
> [line
> #87|https://github.com/apache/avro/blob/master/lang/java/avro/src/main/java/org/apache/avro/util/internal/JacksonUtils.java#L87],
> I see we can auto convert objects into maps, every thing's gonna fine.
> My question is:
> - Is raising exception acceptable?
> - Any other way to have `toJsonNode` for general objects?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AVRO-2793) Schema compatibilty should consider fullname of records
[
https://issues.apache.org/jira/browse/AVRO-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17080848#comment-17080848
]
Doug Cutting commented on AVRO-2793:
Git blame points to AVRO-2400. It looks like folks relied on a relaxed
implementation of an insufficiently clear specification. That's too bad.
> Schema compatibilty should consider fullname of records
> ---
>
> Key: AVRO-2793
> URL: https://issues.apache.org/jira/browse/AVRO-2793
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.9.2
>Reporter: Jurgis Pods
>Priority: Major
>
> Consider the following example:
> {code:java}
> Schema writerSchema = Schema.createRecord("fieldname", null, "namespace1",
> false, Collections.emptyList());
> Schema readerSchema = Schema.createRecord("fieldname", null, "namespace2",
> false, Collections.emptyList());
> // compat.getType() should be SchemaCompatibilityType.INCOMPATIBLE, but is
> actually SchemaCompatibilityType.COMPATIBLE
> SchemaPairCompatibility compat =
> SchemaCompatibility.checkReaderWriterCompatibility(readerSchema,
> writerSchema2){code}
> I would expect the validation to yield an incompatible result, as records
> should have identical fullnames.
> This issue is similar to AVRO-2322, but vice versa: Here the namespace
> differs, not the record name.
> The root cause seems to be in
> [SchemaCompatibility::schemaNameEquals|https://github.com/apache/avro/blob/master/lang/java/avro/src/main/java/org/apache/avro/SchemaCompatibility.java#L97],
> where getName() is used instead of getFullName().
> Is there any reason not to be strict here and use the fullname for
> validation? We ran into severe problems after changing a record's namespace
> in a newer schema version. The Avro schema compatibiltiy check ran through
> fine, so we deployed with confidence. However, the change then caused
> problems both for Confluent's Kafka S3 Connector as well as for Amazon Athena
> when reading data produced by the new schema.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AVRO-2792) Fix C# logical type tests to work in other timezones than UTC
[
https://issues.apache.org/jira/browse/AVRO-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081068#comment-17081068
]
Kengo Seki commented on AVRO-2792:
--
No, that's not what I meant. If we need timezone info, we can define it as
another field in the same record in which the timestamp field is. So we don't
have to update the spec. :)
> Fix C# logical type tests to work in other timezones than UTC
> -
>
> Key: AVRO-2792
> URL: https://issues.apache.org/jira/browse/AVRO-2792
> Project: Apache Avro
> Issue Type: Bug
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Major
>
> I ran the C# unit tests outside of a container and got the following error.
> This is because my machine's timezone is JST (UTC+9).
> {code}
> $ cd lang/csharp
> $ ./build.sh test
> (snip)
> X TestLogical_TimestampMicrosecond() [22ms]
> Error Message:
> Expected: 1990-01-01 14:15:30
> But was: 1990-01-01 05:15:30
> Stack Trace:
> at Avro.Test.Generic.GenericTests.test[T](String s, T value) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 38
>at Avro.Test.Generic.GenericTests.TestLogical_TimestampMicrosecond() in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 139
> X TestLogical_TimestampMillisecond() [< 1ms]
> Error Message:
> Expected: 1990-01-01 14:15:30
> But was: 1990-01-01 05:15:30
> Stack Trace:
> at Avro.Test.Generic.GenericTests.test[T](String s, T value) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 38
>at Avro.Test.Generic.GenericTests.TestLogical_TimestampMillisecond() in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Generic/GenericTests.cs:line
> 133
> X TestTimestampMicrosecond("01/01/2019 14:20:00","01/01/2019 14:20:00Z") [<
> 1ms]
> Error Message:
> Expected: 2019-01-01 14:20:00
> But was: 2019-01-01 05:20:00
> Stack Trace:
> at Avro.Test.LogicalTypeTests.TestTimestampMicrosecond(String s, String
> e) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Util/LogicalTypeTests.cs:line
> 143
> X TestTimestampMillisecond("01/01/2019 14:20:00","01/01/2019 14:20:00Z") [<
> 1ms]
> Error Message:
> Expected: 2019-01-01 14:20:00
> But was: 2019-01-01 05:20:00
> Stack Trace:
> at Avro.Test.LogicalTypeTests.TestTimestampMillisecond(String s, String
> e) in
> /home/sekikn/repos/avro/lang/csharp/src/apache/test/Util/LogicalTypeTests.cs:line
> 119
> Test Run Failed.
> Total tests: 584
> Passed: 580
> Failed: 4
> Total time: 2.3598 Seconds
> {code}
> [As the specification
> says|https://avro.apache.org/docs/current/spec.html#Timestamp+%28millisecond+precision%29],
> Avro's timestamp logical type has a long value that represents the
> difference from the unix epoch (1 Jan 1970 00:00:00 UTC) and it doesn't have
> timezone information. So when deserializing it, it's returned as a C#
> DateTime object with UTC.
> Therefore, if the input string lacks timezone information, we should assume
> it represents UTC datetime in these test cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (AVRO-2749) The Avro ruby gem is unable to encode hashes with non-string keys
[
https://issues.apache.org/jira/browse/AVRO-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fokko Driesprong resolved AVRO-2749.
Fix Version/s: 1.10.0
Resolution: Fixed
> The Avro ruby gem is unable to encode hashes with non-string keys
> -
>
> Key: AVRO-2749
> URL: https://issues.apache.org/jira/browse/AVRO-2749
> Project: Apache Avro
> Issue Type: Improvement
> Components: ruby
>Affects Versions: 1.9.2
>Reporter: Justin Lambert
>Priority: Major
> Fix For: 1.10.0
>
>
> When trying to encode a ruby hash which uses symbols, an error is raised
> because the key lookup is expecting a string only.
> {code:java}
> { id: 4, name: "foo"} =>
> The datum nil is not an example of schema "long"
> (Avro::IO::AvroTypeError){code}
> This error is a bit cryptic and since ruby supports all simple data types as
> hash keys, all keys should be converted to strings before encoding.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AVRO-2749) The Avro ruby gem is unable to encode hashes with non-string keys
[
https://issues.apache.org/jira/browse/AVRO-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081190#comment-17081190
]
ASF subversion and git services commented on AVRO-2749:
---
Commit 01e039ca12ade8bc08b6b4b33ef87a32f3f06b88 in avro's branch
refs/heads/master from Justin Lambert
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=01e039c ]
AVRO-2749: Add ruby support for datum hashes with non-string keys (#819)
* support datum hashes with non-string keys in ruby
* lint fixes
* datum keys as string or symbol only
* empty commit
* empty commit, tests
* empty commit, tests
> The Avro ruby gem is unable to encode hashes with non-string keys
> -
>
> Key: AVRO-2749
> URL: https://issues.apache.org/jira/browse/AVRO-2749
> Project: Apache Avro
> Issue Type: Improvement
> Components: ruby
>Affects Versions: 1.9.2
>Reporter: Justin Lambert
>Priority: Major
>
> When trying to encode a ruby hash which uses symbols, an error is raised
> because the key lookup is expecting a string only.
> {code:java}
> { id: 4, name: "foo"} =>
> The datum nil is not an example of schema "long"
> (Avro::IO::AvroTypeError){code}
> This error is a bit cryptic and since ruby supports all simple data types as
> hash keys, all keys should be converted to strings before encoding.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (AVRO-2749) The Avro ruby gem is unable to encode hashes with non-string keys
[
https://issues.apache.org/jira/browse/AVRO-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fokko Driesprong reassigned AVRO-2749:
--
Assignee: Justin Lambert
> The Avro ruby gem is unable to encode hashes with non-string keys
> -
>
> Key: AVRO-2749
> URL: https://issues.apache.org/jira/browse/AVRO-2749
> Project: Apache Avro
> Issue Type: Improvement
> Components: ruby
>Affects Versions: 1.9.2
>Reporter: Justin Lambert
>Assignee: Justin Lambert
>Priority: Major
> Fix For: 1.10.0
>
>
> When trying to encode a ruby hash which uses symbols, an error is raised
> because the key lookup is expecting a string only.
> {code:java}
> { id: 4, name: "foo"} =>
> The datum nil is not an example of schema "long"
> (Avro::IO::AvroTypeError){code}
> This error is a bit cryptic and since ruby supports all simple data types as
> hash keys, all keys should be converted to strings before encoding.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AVRO-2791) Fix lang/py3/build.sh to process each argument separately
[
https://issues.apache.org/jira/browse/AVRO-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081192#comment-17081192
]
ASF subversion and git services commented on AVRO-2791:
---
Commit 9af218d3c060da103868cdc69d7b39fc8d50dcbc in avro's branch
refs/heads/master from Kengo Seki
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=9af218d ]
AVRO-2791: Fix lang/py3/build.sh to process each argument separately (#852)
> Fix lang/py3/build.sh to process each argument separately
> -
>
> Key: AVRO-2791
> URL: https://issues.apache.org/jira/browse/AVRO-2791
> Project: Apache Avro
> Issue Type: Bug
> Components: build, python
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Minor
>
> I ran {{./build.sh clean test}} in the lang/py3 directory and came across the
> following error:
> {code}
> $ ./build.sh docker
> sekikn@2241fc3fd5a3:~/avro$ cd lang/py3
> sekikn@2241fc3fd5a3:~/avro/lang/py3$ ./build.sh clean test
> running clean
> removing 'avro_python3.egg-info' (and everything under it)
> Removing /home/sekikn/avro/lang/py3/avro/VERSION.txt
> removing '/home/sekikn/avro/lang/py3/avro/__pycache__' (and everything under
> it)
> Removing /home/sekikn/avro/lang/py3/avro/HandshakeResponse.avsc
> Removing /home/sekikn/avro/lang/py3/avro/HandshakeRequest.avsc
> removing '/home/sekikn/avro/lang/py3/avro/tests/__pycache__' (and everything
> under it)
> Removing /home/sekikn/avro/lang/py3/avro/tests/interop.avsc
> running test
> WARNING: Testing via this command is deprecated and will be removed in a
> future version. Users looking for a generic test entry point independent of
> test runner are encouraged to use tox.
> running egg_info
> creating avro_python3.egg-info
> writing avro_python3.egg-info/PKG-INFO
> writing requirements to avro_python3.egg-info/requires.txt
> writing dependency_links to avro_python3.egg-info/dependency_links.txt
> writing top-level names to avro_python3.egg-info/top_level.txt
> writing manifest file 'avro_python3.egg-info/SOURCES.txt'
> reading manifest file 'avro_python3.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'avro/HandshakeRequest.avsc'
> warning: no files found matching 'avro/HandshakeResponse.avsc'
> warning: no files found matching 'avro/VERSION.txt'
> writing manifest file 'avro_python3.egg-info/SOURCES.txt'
> running build_ext
> error: [Errno 2] No such file or directory:
> '/home/sekikn/avro/lang/py3/avro/VERSION.txt'
> {code}
> This is because the main function is implemented as follows. If the arguments
> {{clean test}} are passed to that function, a single command {{python3
> setup.py clean test}} is called.
> Instead, it should call {{setup.py}} for each argument in the for-loop.
> {code}
> main() {
> (snip)
> for target; do
> case "$target" in
> lint) set -- isort "$@";;
> clean|dist|isort|test) :;;
> *) usage; return 1;;
> esac
> done
> python3 setup.py "$@"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AVRO-2791) Fix lang/py3/build.sh to process each argument separately
[
https://issues.apache.org/jira/browse/AVRO-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fokko Driesprong updated AVRO-2791:
---
Fix Version/s: 1.10.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Fix lang/py3/build.sh to process each argument separately
> -
>
> Key: AVRO-2791
> URL: https://issues.apache.org/jira/browse/AVRO-2791
> Project: Apache Avro
> Issue Type: Bug
> Components: build, python
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Minor
> Fix For: 1.10.0
>
>
> I ran {{./build.sh clean test}} in the lang/py3 directory and came across the
> following error:
> {code}
> $ ./build.sh docker
> sekikn@2241fc3fd5a3:~/avro$ cd lang/py3
> sekikn@2241fc3fd5a3:~/avro/lang/py3$ ./build.sh clean test
> running clean
> removing 'avro_python3.egg-info' (and everything under it)
> Removing /home/sekikn/avro/lang/py3/avro/VERSION.txt
> removing '/home/sekikn/avro/lang/py3/avro/__pycache__' (and everything under
> it)
> Removing /home/sekikn/avro/lang/py3/avro/HandshakeResponse.avsc
> Removing /home/sekikn/avro/lang/py3/avro/HandshakeRequest.avsc
> removing '/home/sekikn/avro/lang/py3/avro/tests/__pycache__' (and everything
> under it)
> Removing /home/sekikn/avro/lang/py3/avro/tests/interop.avsc
> running test
> WARNING: Testing via this command is deprecated and will be removed in a
> future version. Users looking for a generic test entry point independent of
> test runner are encouraged to use tox.
> running egg_info
> creating avro_python3.egg-info
> writing avro_python3.egg-info/PKG-INFO
> writing requirements to avro_python3.egg-info/requires.txt
> writing dependency_links to avro_python3.egg-info/dependency_links.txt
> writing top-level names to avro_python3.egg-info/top_level.txt
> writing manifest file 'avro_python3.egg-info/SOURCES.txt'
> reading manifest file 'avro_python3.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'avro/HandshakeRequest.avsc'
> warning: no files found matching 'avro/HandshakeResponse.avsc'
> warning: no files found matching 'avro/VERSION.txt'
> writing manifest file 'avro_python3.egg-info/SOURCES.txt'
> running build_ext
> error: [Errno 2] No such file or directory:
> '/home/sekikn/avro/lang/py3/avro/VERSION.txt'
> {code}
> This is because the main function is implemented as follows. If the arguments
> {{clean test}} are passed to that function, a single command {{python3
> setup.py clean test}} is called.
> Instead, it should call {{setup.py}} for each argument in the for-loop.
> {code}
> main() {
> (snip)
> for target; do
> case "$target" in
> lint) set -- isort "$@";;
> clean|dist|isort|test) :;;
> *) usage; return 1;;
> esac
> done
> python3 setup.py "$@"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
