On Windows, robotpy-build deletes the lib folder then errors out:
error: [WinError 183] Cannot create a file when that file already exists: 'C:\\...\\command2\\lib' . This folder does not need to be manually deleted. If python setup.py develop is run again, it succeeds.

Theory: robotpy-build tries to delete the folder but does not release it's descriptors on the folder. When the descriptor is released (upon error / exit). the folder is deleted.

I believe the way to fix this is make each class wrapper a class, where the declarations are initialized in the constructor (called in toposort order), and then methods are called

class XWrapper {
  py::class<X> cls_X;

  XWrapper(py::module &m) : cls_X(m, "X") {}

  init_methods() {
     cls_X.def( ) ... 
  }
}

For now, I'm going to provide a manual way to override the ordering.

In particular, wpilib.Color needs them.

Something like

void foo(int * x = nullptr);

Most of the out parameter stuff isn't particularly well tested, honestly.

Example:

accelerometer_obj.setRange( accelerometer_obj.Range.kRange_2G )

and

accelerometer_obj.setRange( accelerometer_obj.Range(0) )

work.

But,

accelerometer_obj.setRange( 0 )

does not as it did in 2019.

Potential Solutions:

1. Overload these functions with type int and static cast them to the enum type. This will cast any int to enum. If a user specifies a bad number, we would need to add in a check (or hope the code crashes somewhere else).

For easier customizations.

The output of python -m robotpy_build scan-headers uses backslashes instead for forward-slashes on Windows.

The accepted PEP 600 defines new manylinux tags corresponding to glibc versions. By my understanding, WPILib's linuxx86-64 corresponds to Ubuntu 18.04, which would correspond to the platform tag manylinux_2_27_x86_64.

PEP 599 (manylinux2014) also explicitly allows the armv7l and aarch64 platforms, so we should be good to publish wheels for all WPILib Linux platforms once we have the infrastructure.

That way it's easy to find headers that have been added.

Add more tooooools

https://github.com/robotpy/robotpy-build/blob/main/robotpy_build/tool.py is the module that should be split

We can't easily build these modules on readthedocs -- and honestly, we probably don't want to anyways. Instead, if we had an rst generator template, then readthedocs could just run that and then we'd have docs.

This seems easier than trying to get sphinx to read from pyi files -- and the pyi files would have references to other non-installed modules (which aren't really required to create documentation), so the imports would fail.

Maybe @auscompgeek has a better idea?

Now that we have docs for robotpy-wpilib, we should make sure that the docs make clear what is deprecated.

Related: #36

Users get a 'module not found' error, but the module is actually there. Need to provide a better error message.

Some require keepalive, some don't.

The autogen/warnings stuff should be as follows?

• If a keepalive section is present or empty, no warning
• Not present, issue missing warning
• On autogen, print out keepalive for each pointer parameter.. but comment it out?

Instead of using the inline_cpp block.

In particular, this would be useful for __repr__ methods. Not sure how this would work out..

extra_methods:
  __repr__:
    cpp_code: |
       [](Type * self) { return "<Type>"; }

We can't automatically generate appropriate bindings for functions that take a void pointer, so at the very least the create-gen tool should ignore them, similarly to how it already generates an ignore: true for functions that take initializer_list.

The whole point of using something like schematics is not just massaging data types (which is useful), but it also validates the data and tells the user that they messed up.

pydantic might get this in the future (pydantic/pydantic#1098) but until it does we just end up with erroneous data which you'll never figure out why it's an error.

Not fixing this prevents pyi generation. Can add py::arg_v annotation to address this.

Should be simple.

I think this will allow binding incomplete types, such as wpi::PortForwarder

In

PYBIND11_MODULE(module, m) {
}

the first argument needs to match the extension name.

Another alternative to this is to make it a #define created automatically, then robotpy-build can manage that for you. Maybe RPYBUILD_PYBIND11_MODULE(m)?

This will improve our user experience significantly.

Much of the work for extracting appropriate annotations has actually already been done in the pybind11 for robotpy-rev (which these hooks/templates were derived from). I had removed them because I mistakenly assumed we would only need them for generating sim backends.

Required for robotpy-ctre.

Display things like available libraries, include directories, dependency trees, etc.

For example, if a function is removed, it would be useful to know that and emit a warning

Otherwise when the package doesn't work, dependencies can't be compiled. Mostly a development nice to have.

Let distutils try to save us some time?

It's tricky because we try to delete all the generated files, so we'd need to keep track of this, and track hashes, etc... but it would probably result in a more pleasant development experience assuming distutils does the right thing and doesn't rebuild things that aren't modified.

export CC="ccache gcc"

is recommended in the docs.

This fails to build the .so file on macos.

export CC="ccache clang"
export CXX="ccache clang++"

works. I suppose gcc and g++ instead of clang would work but I haven't tried it.

Imagine a build service that doesn't allow network access.

This would make it easy for me to build packages for various distros.

Would be useful.

These things are going to get huge.

This is a bit limiting.

Loading libraries dynamically via ctypes.LoadLibrary doesn't resolve dependencies, even if you load the dependent libraries first. Seems to be an OSX specific thing, and other python libraries have ran into this (tensorflow)

Indeed, even the default pybind11 library that was generated by robotpy-build isn't able to find the library that it linked to. I suspect this could be addressed by changing the import path.

One potential solution is to install libraries to ~/lib: tensorflow/tensorflow#6729 (comment) ... this is doable with a post-install step but we would want to properly version the library file if we took that approach.

Other potential solutions include changing the libraries via install_name_tool.

pybind11 supports this, so we should add it for the types that make sense.

Environment markers figure into this.

Environment markers are described in several places, including PEP 508. We'd need to figure out an appropriate marker that would differentiate the roborio platform, allow linux, but also work when downloading via pip. I think it might be doable by specifying Linux + CPU type, but maybe we can make it simpler?

RoboRIO:

Python 3.8.1 (default, Dec 30 2019, 05:47:38) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os,sys,platform
>>> os.name
'posix'
>>> sys.platform
'linux'
>>> platform.machine()
'armv7l'
>>> platform.python_implementation()
'CPython'
>>> platform.release()
'4.14.87-rt49-cg-7.0.0f0-xilinx-zynq-189'
>>> platform.system()
'Linux'
>>> platform.version()
'#1 SMP PREEMPT RT Fri Mar 15 19:11:24 UTC 2019'
>>> '.'.join(platform.python_version_tuple()[:2])
'3.8'
>>> platform.python_version()
'3.8.1'
>>> sys.implementation.name
'cpython'
>>> sys.implementation.version
sys.version_info(major=3, minor=8, micro=1, releaselevel='final', serial=0)

From Peter:

A pi with 32-bit raspbian (frcvision image to be precise)

Python 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os,sys,platform
>>> os.name
'posix'
>>> sys.platform
'linux'
>>> platform.machine()
'armv7l'
>>> platform.python_implementation()
'CPython'
>>> platform.release()
'4.19.75-v7l+'
>>> platform.system()
'Linux'
>>> platform.version()
'#1270 SMP Tue Sep 24 18:51:41 BST 2019'
>>> '.'.join(platform.python_version_tuple()[:2])
'3.7'
>>> platform.python_version
<function python_version at 0xb65b16a8>
>>> platform.python_version()
'3.7.3'
>>> sys.implementation.name
'cpython'
>>> sys.implementation.version
sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)

@auscompgeek had recommended the distro module in #37 ... which seems sensible, unfortunately.

Info about what is deprecated is in the headers. We should use that info, reusing the message if possible.

For the classes intended for subclassing in particular, we should add a __init_subclass__ to spit out that warning so that the warning points to where the class is subclassed. Other classes we'd have to add a thing before __init__.

For example, navx doesn't publish binaries for non-roborio platforms: https://www.kauailabs.com/dist/frc/2020/navx_frc.json

Reference in ned14/pcpp#38

The pcpp maintainer doesn't seem to make releases very often, so we might have to either fork or implement a workaround to make the documentation work for kickoff.

Seems like we should do that.

I tried adding it to package_data, but sdist doesn't run build_py so that doesn't get processed.

Setuptools-scm appears to croak if the project doesn't have version metadata associated with it. Might need to roll back e6ffd50.

Filed an issue over at pybind11 about this... but it should be possible to customize our objects with a custom metaclass.

Reference: pybind/pybind11#2103

Environment: Python 3.8.x in Vscode with the python and Intellicode extensions.

The IDE does not provide enums as suggestions to users.

Example:

wpilib.BuiltInAccelerometer.
# OR
wpilib.BuiltInAccelerometer().

At this point, methods such as setRange appear in the menu but Range does not.

Another user faced this issue in pybind/pybind11#1504.

Potential Solutions mentioned in the above issue:

• Use py::class_ instead of py::enum_
• Generate .pyi files

Related to #1

We need to use ours, not the installed version.

Wrong arguments, etc.

The architecture should be "x86-64" but is being set to "x86". This creates a 404 error when downloading files.

Referencing bug report robotpy/robotpy-commands-v1#1

RuntimeError: Tried to call pure virtual function "CxxBase::_isFinished"

This will give the same base for everything. Should fix that.

https://www.python.org/dev/peps/pep-0621/ standardizes storing project metadata in pyproject.toml. We basically do the same thing already, so it would involve reading a different key and deprecating the old mechanism.

I keep coming back to this: https://scikit-build.readthedocs.io/en/latest/index.html

The primary value that robotpy-build provides is wrapper generation and some dependency management -- but maybe we could extract out the wrapper stuff and leverage scikit-build instead?