Installation is complicated

[guettli]

The docs here are outdated (Version 1.9.99): https://github.com/SAP/PyRFC#installation

What is missing to reduce this section of the docs to this?

pip install pyrfc

Above line is simple and contains no version number.

[mpf82]

If you use pip install pyrfc it will install the "pyrfc" package from PyPI: https://pypi.org/project/pyrfc/ - which is a different package.

[bsrdjan]

The safest way of publishing cross platform binary extensions on PyPI is still the source distribution, especially for Linux platforms. The pip install pyrfc would therefore only fetch the sources from PyPI and trigger the build from source on client computer. The build from source requires the toolchain and SAP NWRFC SDK binaries to installed, which is much more work than pip install ... or git clone ....

SAP NWRFC SDK binaries must not be shipped inside PyRFC PyPI package, making it self-contained (legal requirement). They must be separately installed from SAP Service Portal and the pointer to home folder must be provided in SAPNWRFC_HOME variable. Considering inevitable efforts for toolchain and SAP NWRFC SDK installation, the pip install <PyRFC source> or git clone <PyRFC source> makes practically no difference for users, if the build from source is required afterwards. It could help eventually Windows users and can again check the feasibility after dropping Python 2 support.

[mpf82]

@bsrdjan You could link the pre-built wheels on pypi. Other packages do that as well, e.g. pyodbc. (Don't ask me how, I've no idea how the pypi internals work)

There's also the pip switch --prefer-binary, which will try to locate an existing wheel on pypi for the specific Python version & platform and then use that wheel instead of building the package from source.

So you could use pypi and also provide the wheels as you're already doing and users could still decide to use pip install ... with the --prefer-binary switch, without the need to download the wheel from github first.

I just wanted to point out in my previous post, that the package name pyrfc is already in use on pypi by a different project.

[guettli]

The root of the issue is the old fashioned way of distributing SAP NWRFC SDK (download only for registered users)

I guess this way some developers download the library from illegal sources which is much more dangerous.

Changing this goes beyond pyrfc. Where could I ask to make SAP NWRFC SDK freely available?

[bsrdjan]

Freely not possible for the time being because of legal requirements, but will check the space for improvements. Acquiring pyrfc name should be easier part, more challenging are efforts required for publishing cross-platform wrappers of native c++ libs. Will look into this.

[guettli]

"legal requirements" is bit too general. I thought SAP is the owner of the software. Are there reasons why the owner of the software is not allowed to make it public?

[guettli]

Any progress on this fundamental issue? What do the people "above you" say? I have seen this several times before: the people above have fear. They won't do fundamental changes. But the people two steps above you are more open minded. But it is harder to get an "audiance" wiht them.

[bsrdjan]

I don't see the NWRFC SDK unrestricted availability as a fundamental problem here. Even if NWRFC SDK would be free, its registration at OS level required on Linux (conf file, ldconfig ...) can't be automated in a generic way. The manual installation would be still required, just like some elements of the build toolchain (on all platforms).

I would leave this issue open and start investigating the PyPI distribution, assuming the SAP NWRFC SDK (and build toolchain if needed) are installed on target system, with ENV variable SAPNWRFC_HOME pointing to NWRFC SDK root.

[bsrdjan]

The pynwrc package is now published on PyPI, further details in README.

[amarvin]

Awesome work!