amoeba commented on code in PR #3313:
URL: https://github.com/apache/arrow-adbc/pull/3313#discussion_r2285877893
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
+
+Since the manifests will utilize platform tuples to specify the different
systems
+that drivers might be built for, it is important to create a consistent way to
name
+these tuples. Specifically, consistent naming for OS and Architecture
combinations
+that can be used by all systems that read/write manifest files.
+
+As such, the following table should be considered the authoritative list:
+
++---------------+---------------+
+| OS | Tuple Name |
++---------------+---------------+
+| Linux | linux |
+| MacOS | macos |
+| Apple | macos |
Review Comment:
```suggestion
```
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
Review Comment:
```suggestion
Platform Tuples
^^^^^^^^^^^^^^^
```
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
+
+Since the manifests will utilize platform tuples to specify the different
systems
+that drivers might be built for, it is important to create a consistent way to
name
+these tuples. Specifically, consistent naming for OS and Architecture
combinations
Review Comment:
```suggestion
these tuples. Specifically, consistent naming for operating system (OS) and
architecture combinations
```
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
+
+Since the manifests will utilize platform tuples to specify the different
systems
+that drivers might be built for, it is important to create a consistent way to
name
+these tuples. Specifically, consistent naming for OS and Architecture
combinations
+that can be used by all systems that read/write manifest files.
Review Comment:
```suggestion
that can be used by all systems that read and/or write manifest files.
```
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
+
+Since the manifests will utilize platform tuples to specify the different
systems
+that drivers might be built for, it is important to create a consistent way to
name
+these tuples. Specifically, consistent naming for OS and Architecture
combinations
+that can be used by all systems that read/write manifest files.
+
+As such, the following table should be considered the authoritative list:
+
++---------------+---------------+
+| OS | Tuple Name |
++---------------+---------------+
+| Linux | linux |
+| MacOS | macos |
+| Apple | macos |
+| Windows | windows |
+| FreeBSD | freebsd |
+| OpenBSD | openbsd |
++---------------+---------------+
+
++---------------+---------------+
+| Architecture | Tuple Name |
++---------------+---------------+
+| i386 | x86 |
+| x86 | x86 |
+| x86-64 | amd64 |
+| x64 | amd64 |
+| amd64 | amd64 |
+| arm (32-bit) | arm |
+| armbe (32-bit)| armbe |
+| arm64be | arm64be |
+| aarch64 | arm64 |
+| arm64 | arm64 |
+| s390x | s390x |
+| ppc | powerpc |
+| ppc64 | powerpc64 |
+| ppc64le | powerpc64le |
+| riscv | riscv |
+| riscv64 | riscv64 |
+| sparc | sparc |
+| sparc64 | sparc64 |
+| wasm | wasm |
Review Comment:
It seems good to cover both wasm32 and wasm64 since wasm64 seems like a
thing that will happen.
Would `unknown_wasm32`, and `unknown_wasm64` work?
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
+
+Since the manifests will utilize platform tuples to specify the different
systems
Review Comment:
```suggestion
Since the manifests use platform tuples to specify the different systems
```
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
+
+Since the manifests will utilize platform tuples to specify the different
systems
+that drivers might be built for, it is important to create a consistent way to
name
+these tuples. Specifically, consistent naming for OS and Architecture
combinations
+that can be used by all systems that read/write manifest files.
+
+As such, the following table should be considered the authoritative list:
+
++---------------+---------------+
+| OS | Tuple Name |
++---------------+---------------+
+| Linux | linux |
+| MacOS | macos |
Review Comment:
```suggestion
| macOS | macos |
```
##########
docs/source/format/driver_manifests.rst:
##########
@@ -239,6 +239,58 @@ a string (single path) or a table of platform-specific
paths. The ``Driver.shar
needed to successfully load a driver manifest. The other keys are optional,
but provide useful metadata
about the driver.
+Platform-Tuples
+^^^^^^^^^^^^^^^
+
+Since the manifests will utilize platform tuples to specify the different
systems
+that drivers might be built for, it is important to create a consistent way to
name
+these tuples. Specifically, consistent naming for OS and Architecture
combinations
+that can be used by all systems that read/write manifest files.
+
+As such, the following table should be considered the authoritative list:
+
++---------------+---------------+
+| OS | Tuple Name |
++---------------+---------------+
+| Linux | linux |
+| MacOS | macos |
+| Apple | macos |
+| Windows | windows |
+| FreeBSD | freebsd |
+| OpenBSD | openbsd |
++---------------+---------------+
+
++---------------+---------------+
+| Architecture | Tuple Name |
++---------------+---------------+
+| i386 | x86 |
+| x86 | x86 |
+| x86-64 | amd64 |
+| x64 | amd64 |
+| amd64 | amd64 |
+| arm (32-bit) | arm |
+| armbe (32-bit)| armbe |
+| arm64be | arm64be |
+| aarch64 | arm64 |
+| arm64 | arm64 |
+| s390x | s390x |
+| ppc | powerpc |
+| ppc64 | powerpc64 |
+| ppc64le | powerpc64le |
+| riscv | riscv |
+| riscv64 | riscv64 |
+| sparc | sparc |
+| sparc64 | sparc64 |
+| wasm | wasm |
++---------------+---------------+
+
+The construction of the platform tuple is: ``<os>_<arch>``, for example:
``linux_amd64``.
+
+.. note::
+ For alternative scenarios such as using MUSL instead of glibc or MINGw, the
tuple should
Review Comment:
```suggestion
For alternative scenarios such as using musl instead of the GNU C Library
(glibc) or MinGW, the tuple should
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
