I upgraded my Podfile to us
target 'MyApp'
pod 'DropDown'
end
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['ENABLE_BITCODE'] = 'NO'
config.build_settings['SWIFT_VERSION'] = "3.0"
end
end
end
When I try to compile, I get Swift3 compile errors with the DropDown pod. But their page says they support Swift3 natively. https://github.com/AssistoLab/DropDown
I am attempting to use Edit > Convert, I still get errors. Why is this happening? Same issue with AlamoFire. I updated to the latest version by removing the version requirement from the Podfile, removed Pods directory, pod install, updated my swift version to 3.0 in the target settings and I'm getting compile errors.
Rather than removing the version requirement, I would suggest explicitly defining a version that is Swift-3 compatible. It could be that your pods repo is out of date, so it's picking up older versions of the pods.
Related
I am trying to execute a SQL statement on BQ Database by initializing the BQ Client. This has been running smoothly for a while but lately seeing an issue.
My code specifically fails when its trying to wait for the results from the DB
query_job = client.query(QUERY) # API request to start the query
db_rslt = query_job.result() # Wait for the query to return results
Here is error message:
File "/opt/conda/default/lib/python3.7/site-packages/google/cloud/bigquery/job.py", line xxx, in result super(QueryJob, self).result(retry=retry, timeout=timeout) File "/opt/conda/default/lib/python3.7/site-packages/google/cloud/bigquery/job.py", line xxx, in result return super(_AsyncJob, self).result(timeout=timeout) File "/opt/conda/default/lib/python3.7/site-packages/google/api_core/future/polling.py", line xxx, in result self._blocking_poll(timeout=timeout, retry=retry, polling=polling) TypeError: _blocking_poll() got an unexpected keyword argument 'retry'
Added the timeout parameter to the result method but did not help
It depends on the version of your installed google-cloud-bigquery library, if you are using a 1.x version, make sure to set google-api-core to a version less than 1.34.0.
What is actually happening here is that when you install google-cloud-bigquery, a bunch of other google related libraries are installed automatically with it, google-api-core is one of these libraries. However, a higher version is being installed thus causing this problem.
In my case, setting my google-api-core==1.33.2 solves the issue. Other solution would be is to upgrade google-cloud-bigquery to a later version .
7 days ago Google released an update to google-api-core==1.34.0 for bug fixes. I guess this introduced some breaking changes if you are not using the later versions of google-cloud-bigquery. You may either:
Pin google-api-core to the previous working version (eg. 1.33.2)
Upgrade google-cloud-bigquery to the latest versions.
I solved it by changing the bigquery version to the latest: 'google-cloud-bigquery==3.4.0'.
This also happened to me.
My python image is 3.8.13:bulleye.
It was using the following stack of google library.
google-auth==1.33.0
google-cloud-bigquery==1.25.0
google-cloud-firestore==2.3.1
Changing them to
db-dtypes==1.0.0
google-auth==2.6.0
google-cloud-bigquery==3.0.1
google-cloud-firestore==2.5.3
solved the problems.
db-dtypes is required for new version of google cloud library.
This did the trick for me, although I was having this issue on Kaggle notebooks:
pip install -U google-cloud-bigquery google-api-core==1.33.2
Also the v2 version of google-api-core seems to work:
google-api-core==2.11.0
https://github.com/googleapis/python-api-core/releaseshttps://github.com/googleapis/python-api-core/releases
I am using Xcode Version 9.0.1, If I create a new project and install the sdwebimage using cocoapods, it works fine and give no build error.
Where as If I added it to an existing project I am getting:
ld: framework not found SDWebImage
[![clang: error: linker command failed with exit code 1 (use -v to see invocation)][1]][1]
This is how my pod file looks like:
platform :ios, '9.0'
use_frameworks!
target 'test' do
pod 'SDWebImage', '~> 4.0'
pod 'AKSideMenu'
pod 'MBProgressHUD', '~> 1.0.0'
pod 'FacebookCore'
pod 'FacebookLogin'
pod 'FacebookShare', :git => 'https://github.com/1amageek/facebook-sdk-swift'
pod 'CMPageControl'
pod 'ActionSheetPicker-3.0'
pod 'PinCodeTextField', :git => "https://github.com/tkach/PinCodeTextField"
# pod 'Google/SignIn'
pod 'GoogleSignIn'
pod 'Firebase/Core'
pod 'Firebase/Auth'
pod 'Firebase/Database'
pod 'Firebase/Messaging'
pod 'Firebase/Storage'
end
I have check the Framework Search Path and Other Linker Flags Everything looks fine. But I am failing to build the project with sdwebimage.
As a heads up, I tried the solutions above, and they did not work for me -- returned the same error shown above. However, I looked at my terminal from when I installed SDWebImage, and it said something I missed:
[!] Please close any current Xcode sessions and use FILENAME.xcworkspace for this project from now on.
Make sure you are not using the .xcodeproj file like I was. Once I changed to the workspace, everything worked fine.
Try to clean the project's build folder (Product/Clean Build Folder, ^⌘C).
I shutdown my system and then turn it on and I just replace pod 'SDWebImage', '~> 4.0' with pod 'SDWebImage' and it starts to build. I almost wasted 3 hours to get it worked.
One more mistake was, In "Edit Scheme" under Build "Find Implicit Dependencies" was unchecked, That was the main problem, I mark it check and it start working fine.
for my case I did a search for 'SDWebImage' on the side menu. and it turns out that there is a build setting that hasn't been updated yet.
Project Target
Build Settings
Other Linker Flags
please remove if it is bold it will return to the original setting
I just install Xcode 9 and build my native iOS project. (Is written in swift)
The project was OK in Xcode 8 but now, I obtain this error:
No viable overloaded '='
In the file: Pods\Pods\Realm\object.cpp
Line 42 => m_notifier = std::make_shared<_impl::ObjectNotifier>(m_row, m_realm);
If you are using Cocoapods, open up the Podfile and set the RealmSwift version to 2.8.1 (or 2.8.3 as David mentioned above). Here is my Podfile for Swift 3.0 using Xcode 9:
target ‘<PROJECT>’ do
use_frameworks!
# Pods
...
pod 'RealmSwift', '2.8.1'
end
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '3.0'
end
end
end
Then, save the file and run:
pod install
If you're not setting a specific pod version (which I recommend), run the following command:
pod update RealmSwift
and it will automatically update to the most recent version (2.8.3).
Hope it helps to complement David's answer. Thanks!
The Realm team has worked on a new version allowing you to build your project with XCode 9.
Just update your Realm version to at least 2.8.1 (current version is 2.8.3)
https://github.com/realm/realm-cocoa/releases/tag/v2.8.1
The Realm release note of 2.8.1 clearly states :
Add support for building with Xcode 9 Beta 1.
Xcode 8, Swift3, cocoapods 1.1+, ios10
I'm getting error - No such module. Below is my pod file and steps I followed. I even looked at same issues from previous versions and solutions mentioned in other threads didn't work.
Setup
Fresh, brand new Xcode 8 project.
Added Alamofire to my Podfile:
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '10.0'
use_frameworks!
target ‘weatherkaka’ do
pod 'Alamofire', '~> 4.0'
end
Ran the command $ pod install
Install worked fine, and project compiles via workspace file
Opened xcworkspace file
Import: import AlamoFire
I get the error: "No such module: Alamofire".
What am I missing?
Note: I've done clean, re-open Xcode, clean more, re-compile etc. I've added the Alamofire framework to Linked Frameworks and Build phases.
You might get this error for the first time but try to run that project once and it might go away. Also you can command+click the import Alamofire and check that it points to the Alamofire.
You must be using projectName.xcworkspace not the xcodeproj.
In Anaconda I am trying to create an environment using an environment.yml file which begins with the lines:
name: mytest
dependencies:
- anaconda=4.0.0=np110py27_0
However when trying to create the environment, I get the error:
Fetching package metadata .........
Solving package specifications: ....
Error: The following specifications were found to be in conflict:
- anaconda 4.0.0 np110py27_0
Use "conda info <package>" to see the dependencies for each package.
I encountered no problems when I did this seven days ago, but when I tried this yesterday I got the error.
I am running on Windows 7 64-bit as administrator, Anaconda 2.2.0 (Python 2.7 version). The "conda list" output includes conda 4.1.11 and conda-env 2.5.2.
To try to isolate the error, I installed Miniconda2 on a different 64-bit Windows 7 computer (as administrator) that had never had any Anaconda/Miniconda installed before. This is the most recent 64-bit Python 2.7 series (Miniconda2-4.1.11-Windows-x86_64.exe).
But trying to install anaconda=4.0.0=np110py27_0, either to a new environment or to the root environment, both produce the same error I received before:
C:\>conda install anaconda=4.0.0=np110py27_0
Fetching package metadata .........
.Solving package specifications: ....
The following specifications were found to be in conflict:
- anaconda 4.0.0 np110py27_0
Use "conda info <package>" to see the dependencies for each package.
C:\>conda create --name test400 anaconda=4.0.0=np110py27_0
Fetching package metadata .........
.Solving package specifications: ....
The following specifications were found to be in conflict:
- anaconda 4.0.0 np110py27_0
Use "conda info <package>" to see the dependencies for each package.
How can I determine what is causing the conflict, and how could I resolve it, given that conda is not naming a second package in its error message? I have seen responses to other "specifications in conflict" questions in which the answer is often "Install the problematic package to a separate python environment", but in this case the new environment could not be created with the package. Starting from a clean Miniconda install did not work either. I suspect something has changed in the Anaconda repository (which would be consistent with the original environment.yml working in the past but not now), but how would I determine if this is the underlying issue?
Thanks.
The underlying issue was a temporary error in the https://repo.continuum.io/pkgs/free/win-64/repodata.json file, which has since been fixed.
For reference for anyone investigating Anaconda dependency conflicts, here are the details of the investigation, and the workaround for this case:
The cause:
The repodata.json file (linked above) is essentially a 'master list' of the dependencies of the various libraries in https://repo.continuum.io/pkgs/free/win-64/. The "conda" command uses this repodata.json file.
While the problem was occurring, the repodata.json file incorrectly listed "_nb_ext_conf" as a dependency for each version of ipywidgets. (The /info/index.json file inside "ipywidgets-4.1.1-py27_0.tar.bz2" did not list "_nb_ext_conf" as a dependency, however I think newer versions of ipywidgets require it.)
The "_nb_ext_conf-0.2.0-py27_0.tar.bz2" and "_nb_ext_conf-0.3.0-py27_0.tar.bz2" files list "notebook >=4.2.0" as a dependency in their info/index.json files.
The info/index.json file in anaconda-4.0.0-np110py27_0.tar.bz2 file (which is used when you specify "anaconda=4.0.0=np110py27_0" in an environment.yml) lists "ipywidgets 4.1.1 py27_0" as a dependency.
Due to the temporary problem in repodata.json, this "ipywidgets 4.1.1 py27_0" caused conda to think "_nb_ext_conf" needed to be installed, thus causing conda to think "notebook >=4.2.0" also needed to be installed.
But the info/index.json file in anaconda-4.0.0-np110py27_0.tar.bz2 file also specifies that the specific version "notebook 4.1.0 py27_2" must be installed.
The conflicting requirements for "notebook" versions (4.1.0 and >=4.2.0) caused the "specifications were found to be in conflict" error.
The workaround:
First, remove the line "- anaconda=4.0.0=np110py27_0" from the environment.yml file.
Next, replace that line in environment.yml with every library listed in the "depends" section of the info/index.json file from anaconda-4.0.0-np110py27_0.tar.bz2. (Remove the quotation marks, replace the spaces with equals signs, etc. to convert the .json syntax to the environment.yml syntax.)
Finally, remove the "- notebook=4.1.0=py27_2" line from this list.
This new environment.yml file will now list every library which would have been installed by "anaconda=4.0.0=np110py27_0", with the exception of "notebook", but "notebook" will get installed anyway due to the "notebook >=4.2.0" requirement in "_nb_ext_conf" due to "ipywidgets", and/or the "notebook" requirement in "ipywidgets" itself.
Investigative tools:
The command "conda info anaconda=4.0.0=np110py27_0" gives the list of libraries required by the specified package, according to repodata.json. I put this list of libraries into a temporary_environment.yml file. Attempting to create an environment from that temporary_environment.yml file caused conda to specify that "notebook" was involved in the conflict, which gave the hint to try omitting "notebook".
Running "conda info" lists all the libraries currently installed in the active environment. The output for the environment created by temporary_environment.yml was compared to the output from an environment from a computer where "anaconda=4.0.0=np110py27_0" had previously installed successfully. This highlighted "_nb_ext_conf" as one difference.
I created a batch file which ran "conda info" for every library listed in anaconda=4.0.0=np110py27_0, and I looked for instances of "notebook" and "_nb_ext_conf" in the output. This pointed to "ipywidgets" as a suspect.