[BUG] Does not install with setuptools >= 58.0.0 due to suds-jurko dependency

[chenz-svsarrazin]

suds-jurko==0.6 (which this package depends on) does not install with setuptools >= 58.0.0. Since virtualenv installs the most recent setuptools by default, this de facto means that Salesforce-FuelSDK cannot be installed in a fresh env without further workarounds.

Note that is still works if the suds-jurko wheel is already in the pip package cache.

[alexjanakos-sdc]

+1, this has forced us to pin our setuptool version to 57.5.0

[filipgon]

+1. This issue has us stuck, as we are using a different package that automatically forces us to use the latest setuptools as its own dependency. Please consider replacing the dependency to suds-bis (pypa/setuptools#2784 as provided by jaraco)

[nrth]

Running into the same issue, please consider switching to https://github.com/suds-community/suds

[mccordm-odb]

For anyone who is also waiting on a fix. We ended up forking this repo and making the change for suds-community in the requirements.txt. Then in our own requirements.txt for our project we added our forked version of the fuel sdk by overriding the dependency.

https://pip.pypa.io/en/stable/user_guide/#requirements-files

Requirements files are used to override a dependency with a local patch that lives in version control. For example, suppose a dependency SomeDependency from PyPI has a bug, and you can’t wait for an upstream fix. You could clone/copy the src, make the fix, and place it in VCS with the tag sometag. You’d reference it in your requirements file with a line like so:

git+https://myvcs.com/some_dependency@sometag#egg=SomeDependency
If SomeDependency was previously a top-level requirement in your requirements file, then replace that line with the new line. If SomeDependency is a sub-dependency, then add the new line.

e.g. from our requirements.txt
s3transfer==0.3.3 Salesforce-FuelSDK==1.3.0 git+https://github.com/yourForkedRepo/FuelSDK-Python six==1.15.0

[AndreasLuckert]

Are there any plans to implement this fix into the actual repo soon?
Using a forked repo is not really the preferred way, especially not for large-scale projects which require a lot of compliance and security.

[kchristensen]

Is there any hope of this getting fixed, or has Salesforce abandoned this project totally?