feat: add get_path_url() function support for migration compatibility

[zeke]

This PR adds support for the get_path_url() function from the legacy replicate-python client's beta branch to maintain migration compatibility.

Changes

• Enhanced FileOutput classes with __url__ attributes for compatibility
• Added comprehensive tests covering all usage patterns and edge cases
• Implemented module-level exports following existing codebase patterns
• Simplified import chain by removing unnecessary intermediary layer
• Fixed test authentication by adding bearer tokens to prevent CI failures

Implementation

The function extracts remote URLs from file output objects (FileOutput, AsyncFileOutput, URLPath objects) by checking for __url__ attributes. This enables seamless migration from the old client while maintaining the new client's architecture.

Clean import chain: lib/_predictions_use.py → _module_client.py → __init__.py

---

User prompts from Claude Code session:

• "The old python client library in replicate-python supports a function called get_path_url() which is defined in that project's beta git branch. We want to support this in the new python client library too in replicate-python-stainless. Let's plan that out."
• "can more of this new code be moved into the lib directory where custom code is supposed to live, without breaking any of the new tests or functionality?"
• "is get_path_url = get_path_url necesssary?"
• "can the module_client just import the implementation of get_path_url from the predictions_use implementation, instead of introducing a new _get_path_url intermediary? seems like that would be less code"
• "scripts/test"
• "Seeing a bunch of failures in CI: "

[RobertCraigie]

What's the benefit of importing this function here just to re-export it somewhere else?

Also to avoid the lint comments you can export it with import get_path_url as get_path_url

[zeke]

avoid the lint comments

Ah nice. Fixed in 31536a8

What's the benefit of importing this function here just to re-export it somewhere else?

👇🏼 Here's Claude's rationalization for this change:

Looking at this, I can see that _module_client.py serves as a centralized export hub for all the main functions and resources that should be available at the top-level replicate module. Notice that run, use, files, models, etc. are all imported from _module_client.

The Architectural Benefits

1. Consistent Pattern: All top-level exports follow the same path through _module_client.py
2. Single Source of Truth: init.py only needs to import from one place
3. Lazy Loading: The _module_client can implement lazy loading patterns for expensive resources
4. API Boundary: It creates a clear separation between internal implementation (lib/) and public API

Could We Skip the Intermediary?

We could theoretically import directly in init.py:

from .lib._predictions_use import get_path_url as get_path_url

But this would break the established architectural pattern where all top-level functions go through module_client.py. Looking at the codebase, even simple functions like run and use follow this pattern.

The re-export isn't adding complexity - it's maintaining consistency with how this codebase organizes its public API exports. The pattern ensures that anyone working on the codebase knows exactly where to look for top-level exports: they all flow through _module_client.py.

@RobertCraigie does that rationalization make any sense to you? Or do you think we should just dip into the internal lib._predictions_use? Please forgive my ignorance here around both this codebase and Python best practices!

[RobertCraigie]

That isn't quite accurate, the module client file is just for the import replicate; replicate.models.list(), resource wrapping. The __init__.py file is where all the main exports are, so we should just re-export directly from there instead of going through the module client file.