Because device_info_plus 13.2.0 depends on win32 ^6.0.1
and file_picker >=8.3.3 <12.0.0-beta.1 depends on win32 ^5.9.0,
device_info_plus ^13.2.0 is incompatible with file_picker ^11.0.2.

At first, this looks simple: two packages depend on win32, but on different versions.

The annoying part is figuring out where that dependency comes from and what version constraint a specific package version actually declares.

So I built a small tool to make that easier.

The problem

Imagine a Flutter project with:

dependencies:
  file_picker: ^11.0.2
  device_info_plus: ^13.2.0

Running:

flutter pub get

fails because:

file_picker
    → win32 ^5.9.0

device_info_plus
    → win32 ^6.0.1

These constraints don't overlap.

The problem becomes more interesting when the dependency isn't direct.

You might have:

my_app
└── package_a
    └── package_b
        └── win32

Looking only at your pubspec.yaml doesn't tell you the whole story.

Pub already knows the answer

The Dart Pub API contains the published pubspec for every package version.

For example:

curl -s https://pub.dev/api/packages/file_picker

The response contains all published versions.

We can then select a specific version with jq:

curl -s https://pub.dev/api/packages/file_picker |
jq '.versions[] | select(.version == "11.0.2") | .pubspec.dependencies'

For file_picker 11.0.2, this gives:

{
  "flutter": {
    "sdk": "flutter"
  },
  "flutter_web_plugins": {
    "sdk": "flutter"
  },
  "flutter_plugin_android_lifecycle": "^2.0.22",
  "plugin_platform_interface": "^2.1.8",
  "ffi": "^2.1.3",
  "path": "^1.9.0",
  "win32": "^5.9.0",
  "cross_file": "^0.3.4+2",
  "web": "^1.1.0",
  "dbus": "^0.7.11"
}

Now the problem is immediately clear:

file_picker 11.0.2
    └── win32 ^5.9.0

And:

device_info_plus 13.2.0
    └── win32 ^6.0.1

Turning it into a small tool

I didn't want to type the API command manually every time.

The first version is just a small Bash script:

#!/bin/bash

read -p "Package name: " PACKAGE
read -p "Version: " VERSION

echo
echo "Dependencies for $PACKAGE $VERSION:"
echo

curl -fsSL "https://pub.dev/api/packages/$PACKAGE" |
  jq --arg version "$VERSION" '
    .versions[]
    | select(.version == $version)
    | .pubspec.dependencies
  '

Now I can run:

./pub_deps.sh

and enter:

Package name: file_picker
Version: 11.0.2

The tool returns the dependencies declared by that exact package version.

A more useful version

The next step is to make the tool answer a more specific question:

Package: file_picker
Version: 11.0.2
Dependency: win32

Result:
win32 ^5.9.0

And if the package doesn't directly depend on win32:

Package: some_package
Version: 2.0.0
Dependency: win32

Result:
No direct dependency on win32.

This distinction matters because a package can depend on another package that eventually depends on win32.

Direct vs transitive dependencies

There are two different situations:

file_picker
└── win32

Here, win32 is a direct dependency of file_picker.

But you can also have:

package_a
└── package_b
    └── package_c
        └── win32

Here, win32 is a transitive dependency.

Dart's pub deps command is useful once the project successfully resolves:

dart pub deps --style=tree

But there is an important limitation: if pub get fails, there is no resolved dependency graph to inspect.

That's exactly the situation where querying the published package metadata becomes useful.

Why I think this is useful

Package conflicts are common in Flutter projects, especially when working with plugins that depend on platform-specific packages.

The error message from Pub is technically correct, but sometimes you want to investigate the package versions yourself:

Which version introduced this dependency?

What version constraint does this package actually declare?

Did the dependency change between two releases?

Which package is preventing me from upgrading?

Instead of opening several package pages and manually searching through their versions, a small dependency inspector can answer these questions quickly.

The next step

The Bash version is only the beginning.

A proper tool could provide something like:

Dart Dependency Inspector

Package A
file_picker 11.0.2
    └── win32 ^5.9.0

Package B
device_info_plus 13.2.0
    └── win32 ^6.0.1

--------------------------------
CONFLICT

Required ranges:

file_picker:
>=5.9.0 <6.0.0

device_info_plus:
>=6.0.1 <7.0.0

No compatible version exists.

It could also compare package versions and show when a dependency changed between releases.

That would turn a simple API wrapper into something more useful: a small Dart/Flutter dependency investigation tool.

Sometimes a useful developer tool starts with a frustrating pub get error.

Automated Media Stack: Jellyfin, Sonarr, and Prowlarr on Ubuntu

Setting up a home media server doesn't have to be complicated. In this guide, we will deploy a full "Arr" stack using Docker. This setup includes automated downloading, indexing, and a beautiful streaming interface.

🏗️ The Infrastructure

We are using a standard Ubuntu server. This stack includes:

• Jellyfin: The media server (like your personal Netflix).

• Sonarr: Automates TV show management.

• Prowlarr: Manages your indexers and trackers.

• qBittorrent: The download engine.

• FlareSolverr & Byparr: Bypasses search blocks (Cloudflare).

1. Initial Server Setup

First, update your system and install Docker if you haven't already.

# Update system
sudo apt update && sudo apt upgrade -y

# Install Docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker
sudo apt install docker-compose-plugin -y

2. Create the Directory Structure

Organization is key for Docker volumes to work correctly.

mkdir -p ~/houssam/p7/{media/{downloads,tv,movies},configs}
cd ~/houssam/p7

3. The Docker Compose Configuration

Create the docker-compose.yml file:

services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Africa/Casablanca
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent-config:/config
      - /home/your_username/houssam/p7/media/downloads:/downloads
    ports:
      - "8080:8080"
    restart: unless-stopped

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Africa/Casablanca
    volumes:
      - ./sonarr-config:/config
      - /home/your_username/houssam/p7/media/tv:/tv
      - /home/your_username/houssam/p7/media/downloads:/downloads
    ports:
      - "8989:8989"
    restart: unless-stopped

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Africa/Casablanca
    volumes:
      - ./prowlarr-config:/config
    ports:
      - "9696:9696"
    restart: unless-stopped

  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Africa/Casablanca
    volumes:
      - ./jellyfin-config:/config
      - /home/your_username/houssam/p7/media/tv:/data/tvshows
      - /home/your_username/houssam/p7/media/movies:/data/movies
    ports:
      - "8096:8096"
    restart: unless-stopped

  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    container_name: flaresolverr
    environment:
      - LOG_LEVEL=info
      - TZ=Africa/Casablanca
    ports:
      - "8191:8191"
    restart: unless-stopped

Deploy the stack:

docker compose up -d

4. Post-Installation Checklist

🗂️ Step 1: qBittorrent

• URL: http://YOUR_IP:8080

• Action: Change the default username/password in Settings immediately.

📺 Step 2: Sonarr

• URL: http://YOUR_IP:8989

• Setup: Add your root folder as /tv.

• Connect qBittorrent: Settings → Download Clients → Add qBittorrent.

• Host: qbittorrent (if using Docker network) or your Server IP.

🔍 Step 3: Prowlarr

• URL: http://YOUR_IP:9696

• Connect Sonarr: Settings → Apps → Add Sonarr.

• Server: http://sonarr:8989

• API Key: Copy this from Sonarr (Settings → General).

🎬 Step 4: Jellyfin

• URL: http://YOUR_IP:8096

• Action: Follow the wizard and point your libraries to /data/tvshows and /data/movies.

📱 Level Up: Control Everything From Your Phone & TV

The best part of this stack is that you don't need to use a browser once it's set up. You can manage downloads and watch movies using dedicated apps.

1. Watch Anywhere: Jellyfin Mobile & Android TV

The official Jellyfin app is your portal to your movie library.

• Mobile: Available on iOS and Android. Enter your server address: http://YOUR_IP:8096.

• Android TV: You can install the Jellyfin app directly on your Smart TV, Nvidia Shield, or Chromecast with Google TV for a full cinema experience in your living room.

• Pro Tip: For iPad or iPhone, try Swiftfin—it’s a native player that is incredibly fast.

2. Manage on the Go: LunaSea or nzb360

These apps allow you to search for a new movie while you're out and have it ready when you get home.

• LunaSea (iOS/Android): Clean and minimal. Add a "New Profile" for Sonarr using your Server IP and API Key.

• nzb360 (Android): The power user choice. It supports the entire stack and gives you a beautiful "Coming Soon" calendar.

Extra types :

🔐 Public vs. Private Indexers: Why Quality Matters

When you first set up Prowlarr, you might be tempted to just add every public site you find. However, not all torrents are created equal.

Public Indexers (The "Wild West")

Public sites (like 1337x or The Pirate Bay) are open to everyone.

• The Problem: Torrents are often old, "dead" (no seeders), or low quality. Because anyone can upload, you also run a higher risk of downloading fake files or broken releases.

• Speed: Since there is no requirement to "seed" (share) back, many people download and immediately stop sharing, leading to slow speeds.

Private Indexers (The "VIP Club")

Private indexers are closed communities that require an account.

• The Benefit: These sites have strict rules. Members must maintain a good "ratio" (share as much as they download), which means lightning-fast download speeds and high-quality files that stay alive for years.

• Quality Control: Files are often verified by the community to ensure they are high-definition and safe.

🎟️ How to Get Into Private Indexers (For Free)

Most private trackers are "Invite Only," but you don't need to pay for them. Here is how you can get in for free:

1. Monitor "Open Signups": Many great private trackers open their doors for a few hours every month to let new members in.

2. Use Reddit: Join the r/OpenSignups community. Set up an alert so you get a notification the moment a high-quality private indexer opens its registration.

3. Interview/Application: Some elite trackers (like MAM or RED) allow you to join by passing a simple "knowledge interview" about how torrenting works.

Integrating with Prowlarr

Once you get an account on a private site, simply go to Prowlarr > Add Indexer, search for the site name, and enter your API Key or Cookie from that site. Prowlarr will then automatically sync that high-quality source to Sonarr.

That’s it! You now have a high-end streaming service that you own and control completely. Happy watching!

How I built a reusable Flutter package to drop Google, Facebook, and Instagram sign-in into any project in minutes — not days.

Tags: flutter dart oauth bloc open-source

Every new project I started had the same painful ritual: configure Google OAuth, set up Facebook Auth, wrestle with Instagram's WebView flow, wire up a BLoC, handle errors, translate messages… all over again. So I stopped repeating myself and built oauth_connection — a Flutter package that bundles all of it into a single, drop-in integration.

The Problem Worth Solving

OAuth integration sounds simple on paper. In practice, it is three separate SDKs, three sets of platform setup steps, three state machines to manage, and a handful of edge cases — cancelled logins, token fetch failures, missing backend responses — that all need graceful handling. Multiply that by every project and you have a reliable recipe for wasted days.

I wanted a package with a clear contract: initialize once, drop a button widget anywhere, and get a clean token back (or a typed error state). No boilerplate scattered across your codebase.

💡 Design goal: The consuming app should only care about two things — the success token and the failure reason. Everything else is the package's problem.

What's Inside the Package

The package covers three providers, each with sign-in and sign-up flows:

Each provider follows the same structure: a Controller (singleton, handles SDK calls and HTTP), a Cubit (BLoC state management), and ready-to-use Button widgets with built-in loading and error states.

Architecture at a Glance

The package is organized around a clean three-layer architecture. The UI never talks to the SDK directly — it only fires a Cubit method and listens to typed states.

┌─────────────────────────────────────────────┐
│         UI Layer                            │
│   SignInButton / SignUpButton               │
└────────────────────┬────────────────────────┘
                     ↕
┌─────────────────────────────────────────────┐
│         State Layer (BLoC / Cubit)          │
│   GoogleAuthCubit / FacebookAuthCubit /     │
│   InstagramAuthCubit                        │
└────────────────────┬────────────────────────┘
                     ↕
┌─────────────────────────────────────────────┐
│         Controller Layer                    │
│   GoogleAuthController /                   │
│   FacebookAuthController /                 │
│   InstagramAuthController                  │
└────────────────────┬────────────────────────┘
                     ↕
┌─────────────────────────────────────────────┐
│         SDK & Network Layer                 │
│   google_sign_in · flutter_facebook_auth ·  │
│   WebView · http                            │
└─────────────────────────────────────────────┘

Setting Up the Controllers

Each controller is a singleton initialized once — ideally in main() before runApp. Here's Google as an example:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  // Initialize Google OAuth controller once
  await GoogleAuthController.init(
    serverClientId: 'YOUR_SERVER_CLIENT_ID',
    clientId:       'YOUR_CLIENT_ID',
    host:           'api.yourapp.com',
    loginEndpoint:  '/auth/google/login',
    registerEndpoint: '/auth/google/register',
    debugLogs: true, // flip off in production
  );

  runApp(const MyApp());
}

Facebook and Instagram follow the same pattern — call FacebookAuthController.init() and InstagramAuthController.init() with your app credentials and backend endpoints.

Dropping a Button Into Your UI

Once initialized, adding sign-in is a single widget. The button manages its own loading state — it disables itself while the OAuth flow is in progress, so you never need a separate boolean in your page's state.

GoogleSignInButton(
  showErrorMessage: true,
  onSuccess: (GoogleAuthSuccess state) {
    // state.accessToken is ready — store it, navigate, etc.
    saveToken(state.accessToken);
    navigateHome();
  },
  onFailure: (GoogleAuthFailure state) {
    // state.translatedMessage is already localized
    showSnackBar(state.translatedMessage);
  },
)

The same API shape exists for FacebookSignInButton, FacebookSignUpButton, GoogleSignUpButton, InstagramSignInButton, and InstagramSignUpButton.

How the Google Flow Works Internally

The Google controller takes advantage of the new event-stream API introduced in google_sign_in v7. Rather than awaiting a one-shot future, it subscribes to a stream of authentication events — which handles both fresh logins and re-authentication cleanly.

// Inside GoogleAuthController.configure()
_googleSignIn.authenticationEvents.listen((event) async {
  if (event is GoogleSignInAuthenticationEventSignIn) {
    currentUser = event.user;

    if (action == SIGN_IN) {
      await _login(
        email: event.user.email,
        accessToken: await getAccessToken(),
      );
    } else if (action == SIGN_UP) {
      await _register(
        email: event.user.email,
        accessToken: await getAccessToken(),
      );
    }
  }
  // Resolve the Completer so the Cubit knows we're done
  _authCompleter?.complete();
});

A Completer bridges the event-driven SDK and the await-friendly Cubit interface — the Cubit simply does await controller.login() and knows the flow is finished when it returns, regardless of success or failure.

Instagram's Custom WebView Flow

Instagram's OAuth doesn't have an official Flutter SDK, so I built one inside the package. It opens a WebView pointed at Instagram's authorization URL, intercepts the redirect containing the one-time code, and pipes it to your backend.

final String fullAuthUrl =
  "https://api.instagram.com/oauth/authorize"
  "?client_id=$clientId"
  "&redirect_uri=${Uri.encodeComponent(redirectUrl)}"
  "&scope=instagram_business_basic"
  "&response_type=code";

FlutterInstagramApi.login(
  context,
  instaConfig: InstaConfig(
    clientId: clientId,
    instaUrl: fullAuthUrl,
  ),
  oneTimeCode: (code) async {
    // Exchange the code with your backend
    await _login(code);
    onComplete();
  },
  onCancel: () {
    errorCode = "CANCELLED";
    onComplete();
  },
);

Error Handling & Typed States

One of the design decisions I'm most satisfied with is the typed error system. The Cubit emits discrete states:

• GoogleAuthInitial
• GoogleAuthLoading
• GoogleAuthSuccess — carries accessToken
• GoogleAuthFailure — carries errorCode + translatedMessage

The error codes map to real scenarios:

Built-in Localization — 4 Languages

The package ships with its own OAuthConnection.delegate that you add alongside your app's localization delegates. All error and UI strings are available in:

• 🇺🇸 English
• 🇪🇸 Spanish
• 🇫🇷 French
• 🇸🇦 Arabic (including RTL support)

MaterialApp(
  localizationsDelegates: [
    OAuthConnection.delegate, // ← add this
    GlobalMaterialLocalizations.delegate,
    GlobalWidgetsLocalizations.delegate,
  ],
  supportedLocales: const [
    Locale('en'),
    Locale('es'),
    Locale('fr'),
    Locale('ar'),
  ],
)

Key Dependencies

Why I Built This

The Flutter ecosystem has individual packages for each OAuth provider — but nothing that unifies them behind a consistent API, manages state via BLoC, talks to your own backend, and handles errors in multiple languages. oauth_connection fills that gap.

The real value isn't the lines of code. It's that the next time I start a project that needs social login, I spend ten minutes on configuration, not two days on integration.

I plan to expand the package with Apple Sign-In support and a more flexible backend integration API. If you try it out or spot an improvement, I'd love to hear from you.

Built with Flutter · BLoC · Google Sign-In · Facebook Auth · Instagram OAuth

📦 Check out the package on GitHub: github.com/houssam15/oauth_connections

If it helped you, drop a ⭐ — it means a lot!