Closed eernstg closed 4 weeks ago
Its because the package depends on package:macros
, but does not depend on an SDK that supports that specific macros version:
Because macros >=0.1.2-main.2 <0.1.2-main.4 depends on _macros 0.3.1 from sdk which doesn't match any versions, macros >=0.1.2-main.2 <0.1.2-main.4 is forbidden.
And because analyzer >=6.6.0 depends on macros >=0.1.2-main.3 <0.1.3 and macros >=0.1.2-main.4 depends on _macros 0.3.2 from sdk, analyzer >=6.6.0 requires _macros 0.3.2 from sdk.
See https://github.com/dart-lang/pub-dev/issues/7597
/cc @jakemac53 @jonasfj
Thanks! But the dependency on macros
is indirect, it's presumably via analyzer
. So the fix would be to depend on a different version of analyzer
? (Currently it's 6.7.0 and the SDK lower bound is 3.4.0).
And why does it not get reported locally? ;-)
Hm, on a second look, I'm not sure about the core of the issue anymore.
OK, thanks for looking into this! (As we all know, Scores matter ;-).
@eernstg: what's your local SDK version?
The tools? I'm using '3.5.0-259.0.dev' and bleeding edge (f274b8a4c462b0215ca9d77c509c5b88c06c386a).
I just created yet another version (4.0.8) where 'analyzer' is downgraded to 6.5.0, that doesn't help (and I still don't see the errors locally that Pana reports).
The local difference comes because pub.dev was not able to pick a beta/dev SDK (on the score page it says Analyzed with Pana 0.22.7, Dart 3.4.4.
), while you have a dev release locally. The decision to select the SDK is based on the package's pubspec.yaml
:
environment
constraint can be matched with the pre-configured stable, it will use that (IIRC this is the case here)sdk
or the flutter
constraint requires a newer SDK, either the latest stables or the latest betas or the latest dev/master releases will be selected.I'm not fully grasping how the macros
dependency conflict is there, but the above linked issue seems to be related.
OK, thanks a lot!
I published yet another version, 4.0.9, with a narrower range analyzer: '>=6.5.0 <6.7.0
. If it does not have that limitation at the top then it will select analyzer 6.7.0 for dart pub upgrade
and analyzer 6.5.0 for dart pub downgrade
, and they have incompatible libraries. (With 6.5.0 I cannot import 'package:analyzer/source/file_source.dart' because it doesn't yet exist, with 6.7.0 I must import that one).
So it's working fine now. But apparently I have to be very careful about versions at this time. ;-)
You really shouldn't have this <6.7.0
constraint - that is going to hurt future users by not allowing them to get the latest analyzer. Personally, I would opt for broken analysis on pub over a less useful package.
I also don't understand why it would help....
I used to have the constraint ^6.7.0, but that creates an analysis failure with macros, then I tried ^6.5.0, but that creates an analysis failure with a library (something like 'source_resource.dart' that doesn't exist in 6.7.0 and 'file_source.dart' that doesn't exist in 6.7.0). But I hope it's possible to use 6.7.0 soon without any conflicts.
I used to have the constraint ^6.7.0, but that creates an analysis failure with macros
This is just on pub though right? That issue should get resolved once 3.5 stable is released.
just on pub
Yes, that's correct.
That issue should get resolved once 3.5 stable is released.
Sounds good, thanks! I planned to remove that upper bound as soon as possible, so it's good to know that it will indeed be soon.
Note: I'm looking into improving the pub.dev SDK selection logic, ideally without running an upfront pub get
on the analyzed package.
So the resolution issue was fixed by going to analyzer: ^6.5.0
.
The problem with:
(With 6.5.0 I cannot import 'package:analyzer/source/file_source.dart' because it doesn't yet exist, with 6.7.0 I must import that one).
That is an analyzer issue, probably you shouldn't import package:analyzer/source/file_source.dart
if it doesn't exist in 6.5.0
.
Not sure why, you think you need to :rofl:
I'm guessing you were importing package:analyzer/src/source/file_source.dart
, which does still exist.
It's just now annotated with:
@Deprecated('Import package:analyzer/source/file_source.dart')
library;
The fix for that is continue importing it, but add a comment or two:
// TODO: Use 'package:analyzer/source/file_source.dart' when analyzer constraint can be bumped to ^6.7.0
// ignore: deprecated_member_use
import 'package:analyzer/src/source/file_source.dart';
Using a deprecated field, library or member is perfectly fine. Certainly as fine as importing stuff from package:analyzer/src/
.
Indeed we could argue that pana
shouldn't reduce package score just because a package is using deprecated stuff. Indeed, I don't think pana
will reduce score if the deprecation warning is surpressed with an // ignore:
-style comment.
So... this is maybe overkill, but in a perfect world, I guess pana
would:
dart pub upgrade && dart analyze
dart pub downgrade && dart analyze
Of course, I still think pana
should ignore deprecation warnings when the user explicitly ignores them with an //ignore:
-style comment.
That is an analyzer issue, probably you shouldn't import package:analyzer/source/file_source.dart if it doesn't exist in 6.5.0.
I used analyzer: ^6.7.0
at first, and imported 'package:analyzer/source/file_source.dart' because it contains declarations I need. This causes a (pub.dev-only) failure during static analysis, based on some version constraints involving macros that do not have a solution.
So I followed the advice given here and used analyzer: ^6.5.0
. With 6.5.0 I need to import 'package:analyzer/src/source/source_resource.dart' in order to get access to the declarations that later went to 'package:analyzer/source/file_source.dart' (which doesn't exist in 6.5.0). Resolution will then choose analyzer 6.7.0 (with dart pub upgrade
), where 'package:analyzer/src/source/source_resource.dart' causes a failure (because this library is deprecated in 6.7.0).
Finally, I used analyzer: '>=6.5.0 <6.7.0'
(note: not including 6.7.0), which doesn't give rise to any failures.
The fix for that is continue importing it, but add a comment or two:
Thanks! I did not expect the // ignore
comment to have that effect. I'll try it out on the next update.
I believe that the pana change, the 3.5 SDK becoming stable and the update the package makes this issue now obsolete. Please reopen if something is still missing.
I just published a new version of the package reflectable at https://pub.dev/packages/reflectable (version 4.0.7).
The scores are very low, because (apparently) the code doesn't pass static analysis.
However, no issues arise during static analysis locally:
dart pub get
``` > dart pub get Resolving dependencies... (1.1s) Downloading packages... + _fe_analyzer_shared 72.0.0 + _macros 0.3.1 from sdk dart + analyzer 6.7.0 + args 2.5.0 + async 2.11.0 + boolean_selector 2.1.1 + build 2.4.1 + build_config 1.1.1 + build_daemon 4.0.2 + build_resolvers 2.4.2 + build_runner 2.4.11 + build_runner_core 7.3.1 + build_test 2.2.2 + built_collection 5.1.1 + built_value 8.9.2 + checked_yaml 2.0.3 + code_builder 4.10.0 + collection 1.19.0 + convert 3.1.1 + coverage 1.8.0 + crypto 3.0.3 + csslib 1.0.0 + dart_style 2.3.6 + file 7.0.0 + fixnum 1.1.0 + frontend_server_client 4.0.0 + glob 2.1.2 + graphs 2.3.1 + html 0.15.4 + http_multi_server 3.2.1 + http_parser 4.1.0 + io 1.0.4 + js 0.7.1 + json_annotation 4.9.0 + lints 4.0.0 + logging 1.2.0 + macros 0.1.2-main.3 (0.1.2-main.4 available) + matcher 0.12.16+1 + meta 1.15.0 + mime 1.0.5 + node_preamble 2.0.2 + package_config 2.1.0 + path 1.9.0 + pool 1.5.1 + pub_semver 2.1.4 + pubspec_parse 1.3.0 + shelf 1.4.2 + shelf_packages_handler 3.0.2 + shelf_static 1.1.2 + shelf_web_socket 2.0.0 + source_map_stack_trace 2.1.1 + source_maps 0.10.12 + source_span 1.10.0 + stack_trace 1.11.1 + stream_channel 2.1.2 + stream_transform 2.1.0 + string_scanner 1.2.0 + term_glyph 1.2.1 + test 1.25.8 + test_api 0.7.3 + test_core 0.6.5 + timing 1.0.1 + typed_data 1.3.2 + vm_service 14.2.4 + watcher 1.1.0 + web 0.5.1 + web_socket 0.1.5 + web_socket_channel 3.0.0 + webkit_inspection_protocol 1.2.1 + yaml 3.1.2 Changed 70 dependencies! 1 package has newer versions incompatible with dependency constraints. Try `dart pub outdated` for more information. ```dart analyze lib
``` > dart analyze lib No issues found! ```dart pub upgrade
``` > dart pub upgrade Resolving dependencies... (1.1s) Downloading packages... macros 0.1.2-main.3 (0.1.2-main.4 available) No dependencies changed. 1 package has newer versions incompatible with dependency constraints. Try `dart pub outdated` for more information. ```dart pub outdated
``` > dart pub outdated Showing outdated packages. [*] indicates versions that are not the latest available. Package Name Current Upgradable Resolvable Latest direct dependencies: all up-to-date. dev_dependencies: all up-to-date. transitive dependencies: macros *0.1.2-main.3 *0.1.2-main.3 *0.1.2-main.3 0.1.2-main.4 all dependencies are up-to-date. ```Note in particular that
dart pub get
reports "1 package has newer versions incompatible with dependency constraints", which wouldn't be the starting point for changing anything (we can't use that newer version). Moreover,dart pub upgrade
reportsall dependencies are up-to-date
.But the 'Scores' page reports that
dart pub get
failed, the section 'Support up-to date dependencies says that "dart pub get
failed".In the log I can see this:
So why would Pana fail when
dart pub outdated
(and other commands) locally do not report any issues that imply a need to make any changes?