paypal-checkout-sdk breaks in ruby 3.0.1 - paypal

Ruby 3.0.1
Rails 6.1.3.2
Executing a Paypal OrdersCreateRequest fails with this error
NoMethodError (undefined method `escape' for URI:Module):
The backtrace points to .rvm/gems/ruby-3.0.1/gems/paypalhttp-1.0.0/lib/paypalhttp/serializers/form_encoded.rb:8:in `block in encode' which contains this line as of paypalhttp v1.0.0
encoded_params.push("#{URI.escape(k.to_s)}=#{URI.escape(v.to_s)}")
Apparently the URI.escape method was removed in ruby 3 as stated here https://github.com/ruby/uri/issues/14
Is there a workaround for this or I have to just wait for Paypal to update the gem? I do not want to downgrade to ruby 2.x

You could monkeypatch it:
module URI
def self.escape(*args)
URI.encode_www_form_component(*args)
end
end

Related

Error connecting to databricks in python with databricks-connect

I'm using databricks-connect on mac using pycharm but after I finished the configuration and tried to run databricks-connect test, I got the following error and have no idea what the problem is. I followed this documentation: https://docs.databricks.com/user-guide/dev-tools/db-connect.html
The error message is as below:
scala> spa
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.7/bin/databricks-connect", line 11, in
load_entry_point('databricks-connect==5.3.1', 'console_scripts', 'databricks-connect')()
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pyspark/databricks_connect.py", line 244, in main
test()
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pyspark/databricks_connect.py", line 213, in test
raise ValueError("Scala command failed to produce correct result")
ValueError: Scala command failed to produce correct result
Maybe your Java/Python version does not comply. Check your cluster, which Python version does it use (in my case it was 3.5).
And what's most important: check which JDK version do you have on your computer.
In my case, I've had the latest one, which was not supported by databricks-connect. It needs to run on JDK 8.
I would make sure you are using the right version of the Databricks Runtime (DB Connect only currently supports 5.1-5.5). Since these is a limit on the DBR that works with DB connect, you'll have to make sure you match the python version as well (for the base Databricks runtime, I believe it is 3.5.x).
To ignore the RUNTIME version, export an environment variable that resolves:
export DEBUG_IGNORE_VERSION_MISMATCH=1

There's invalid syntax in pub.py

The followed method is defined in the pubsub.py which is a python file in the site-package pubsub. When I try to use this, the pycharm tells me this is invalid syntax with an arrow pointing to '->'. I don't why and I have installed the pypubsub.
def getDefaultPublisher() -> Publisher:
"""
Get the Publisher instance created by default when this module
is imported. See the module doc for details about this instance.
"""
return _publisher
You have a Python version mismatch. This version of PyPubSub needs Python3. Last version for Python2 is PyPubSub 3.3.0
pip install PyPubSub==3.3.0

Julia version 0.4.5 Openstreetmap

I was using Julia version 0.3.2, I updated it to version 0.4.5. Now when I am using OpensteetMap package I am getting error:
ERROR: LoadError: LoadError: LoadError: UndefVarError: Bounds not defined
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:320
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:320
in require at ./loading.jl:259
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:320
in process_options at ./client.jl:280
in _start at ./client.jl:378 while loading /home/nandani/.julia/v0.4/OpenStreetMap/src/crop.jl,
in expression starting on line 6 while loading /home/nandani/.julia/v0.4/OpenStreetMap/src/OpenStreetMap.jl,
in expression starting on line 38.
OpenStreetMap.jl is dependent on Geodesy.jl, where Bounds was defined. But that was removed on April 10th. It made it into the 0.1.0 tag 7 days ago. That tag doesn't support Julia v0.3, so on Julia v0.3 you are still using the older version of Geodesy.jl, which works.
For now, as a workaround, you can pin Geodesy to the older version v0.0.1:
Pkg.pin("Geodesy", v"0.0.1")
and that should make things work on Julia v0.4.5 again.
I submitted an issue so that this can be resolved without requiring the pin.

Uncaught exception 'Zend_Config_Exception' with message 'Comments starting with '#' are deprecated

I have developed a web application and deployed the same under php version 5.2.13 but when i shifted the same to server having PHP Version 5.3.6 it started to give me the error
Uncaught exception 'Zend_Config_Exception' with message 'Comments
starting with '#' are deprecated in ...
Please suggest any workaround to run the same without downgrading the php version.
The clue is in the error. You can no longer comment out lines in an ini file using a hash, use a semi-colon instead. If you simply change this in whichever ini file it's complaining about the error should disappear.
Edit: Since the error is coming from Zend_Config I'm assuming it's an ini file it's complaining about. If it's a PHP script then use // to comment out the line instead.

Zend_Tool CLI issues, throwing fatal errors

Before installing PHPUnit on my Ubuntu machine, I thought I had zf.sh all set up correctly. I was able to create a new project without any issues. Now, since installing PHPUnit, everything is not working right.
When I try to create a test project, I get this:
Fatal error: Cannot redeclare class PHPUnit_Framework_TestSuite_DataProvider in /usr/share/php/PHPUnit/Framework/TestSuite/DataProvider.php on line 64
Call Stack:
0.0011 110200 1. {main}() /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/bin/zf.php:0
0.0011 110320 2. zf_main() /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/bin/zf.php:23
0.0113 685448 3. zf_run() /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/bin/zf.php:36
0.0113 685568 4. Zend_Tool_Framework_Client_Console::main() /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/bin/zf.php:214
0.0114 686044 5. Zend_Tool_Framework_Client_Abstract->dispatch() /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/library/Zend/Tool/Framework/Client/Console.php:96
0.0114 686164 6. Zend_Tool_Framework_Client_Abstract->initialize() /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/library/Zend/Tool/Framework/Client/Abstract.php:209
0.0152 866128 7. Zend_Tool_Framework_Loader_Abstract->load() /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/library/Zend/Tool/Framework/Client/Abstract.php:118
0.4374 2729116 8. include_once('/usr/share/php/PHPUnit/Framework/TestSuite/DataProvider.php') /opt/ZendFramework/ZendFramework-1.9.3PL1-minimal/library/Zend/Tool/Framework/Loader/Abstract.php:90
What do I need to do to get it working again?
Update: I think I understand the reason why this is happening. In PHPUnit 3.4.0 there is a class with the same name as the Zend Framework 1.9.3. Apparently it is a known issue. But how can I get around this so I can use Zend_Tool again?? Can I downgrade PHPUnit? Will that fix the problem?
Update: This tutorial mentions something about installing a diff patch.
I found a temporary workaround:
Edit PHPUnit/Framework.php, near line 70:
require 'PHPUnit/Framework/TestSuite/DataProvider.php';
Change to:
require_once 'PHPUnit/Framework/TestSuite/DataProvider.php';
This is probably not the long-term fix, but it resolves the immediate symptom.
Update 2009-11-20: I just saw a commit to the ZF 1.9 branch that claims to resolve this issue. Presumably the fix will be in the next point-release (1.9.6) and in subsequent minor releases (1.10.0 and later).
Another solution, which doesn't require to change any 3th party code, is copying the PHPUnit folder to a location outside the include_path and create a symlink to the new location instead.
For details on this issue have a look here: Zend_Tool troubles PHPUnit