Invalid PyTorch version pin and missing Sense2Vec model break fresh setup

[HamidKhan1001]

📄 Issue Description
Summary

While setting up the project from a fresh clone, I ran into two issues that prevent the backend from running successfully out of the box.

1. Invalid PyTorch version in requirements.txt

The project pins PyTorch to a version that is not currently available on PyPI (e.g. torch==2.5.1).

This causes pip install -r requirements.txt to fail with:

ERROR: No matching distribution found for torch==2.x.x

On macOS (and generally on PyPI), the latest stable and available version appears to be torch==2.2.2, which works correctly with the rest of the stack.

2. Backend crash due to missing Sense2Vec model

On startup, the backend tries to load a local Sense2Vec model:

Sense2Vec().from_disk("s2v_old")

However, the s2v_old/ directory is not present in the repository, nor referenced in the setup documentation.
This results in a runtime crash on first run:

ValueError: Can't read file: s2v_old/strings.json

Impact

Fresh installs fail during dependency installation

Backend crashes even after successful installs

New contributors cannot run the project without manual debugging

Suggested approach (happy to help)

If this makes sense to the maintainers, I’d be happy to open a PR that:

Pins PyTorch to a valid, stable version available on PyPI

Handles a missing Sense2Vec model gracefully (e.g. optional loading or a clearer warning)

Optionally improves setup documentation around required models

Please let me know if you’d like me to proceed with a PR or if there’s a preferred approach.

Thanks!

[SxBxcoder]

Hey @HamidKhan1001, nice catch!

I actually have a PR waiting for this exact issue (PR #387). It was temporarily closed pending a fix for the scipy and transformers version bounding (to prevent breaking changes in 1.15+), which I've since resolved and pushed.

The updated configuration resolves the dependency conflicts and the s2v model loading crashes. I've just pinged the maintainers to reopen it so we can merge the fix without duplicating the effort. Thanks for flagging it!

[HamidKhan1001]

Thanks for the detailed update, @SxBxcoder — really appreciate the context.

It’s great to hear that PR #387 already addresses both the invalid torch pinning and the Sense2Vec loading issues, along with the additional work on scipy and transformers bounds. That should significantly improve the out-of-the-box setup experience, especially for new contributors and Windows users.

Happy to help with testing once it’s reopened or merged, or to assist with any follow-up documentation updates if needed. Thanks again for the quick turnaround on this.

[SxBxcoder]

@HamidKhan1001 Thanks for verifying that the fix works!

@yatikakain @Aditya062003 Since this is blocking new Windows contributors, I can push a single fresh PR today that resolves everything at once:

Fixes the Crash: Strictly pins torch, scipy, and transformers to compatible versions and adds the missing sense2vec model download.

Adds Documentation: Includes the "Windows Setup Guide" (originally from my PR #390) so new users have clear instructions that match the fixed code.

This would supersede my older PRs (#387 & #390) and close this issue with a single merge. Let me know if I should go ahead.

[SxBxcoder]

@HamidKhan1001 Thanks for closing this, but since the fix (PR #387 / fresh PR) hasn't been merged yet, the crash will still happen for other new contributors.

@yatikakain Could we please reopen this issue until the fix is merged? Or I can open a fresh PR right now that references this issue to close it properly.

I'm ready to push the consolidated fix (Code + Docs) immediately.

[HamidKhan1001]

Hey @SxBxcoder,

I appreciate the work you've done on PR #387 and #430. However, I want to clarify that this issue is not closed yet and requires further attention.

I've opened a separate PR (#425) that addresses some immediate concerns I encountered:

1. Documentation fixes - Fixed broken markdown in the README and clarified backend setup instructions (Python version requirements, working directory)
2. Code cleanup - Removed duplicate imports in backend/Generator/main.py that were causing warnings

Regarding the Sense2Vec model issue - I agree this is a deeper problem that needs proper handling. I'm currently investigating this and working on a solution that gracefully handles the missing model scenario rather than just crashing.

My PR is focused on making the setup documentation clearer and cleaning up code quality issues, while I continue working on the model loading problem separately. I believe both efforts can complement each other.

Let me know if you'd like to coordinate our approaches.

Thanks!

[HamidKhan1001]

Reopening this issue to address the PyTorch version mismatch separately.

While @SxBxcoder has PR #430 in progress, I'd like to contribute a focused fix for the torch version pinning issue specifically.

What I can address now:

• Fix invalid PyTorch version pin in requirements.txt to a stable, available version

What needs deeper work (separate effort):

• Sense2Vec model loading - this requires proper error handling and documentation, which I'm investigating separately

I'll open a PR shortly that focuses only on the dependency version fix.

[SxBxcoder]

Hey @HamidKhan1001 , thanks for reopening this and for your work on #425 .

Regarding the dependency fixes: PR #430 already resolves the torch version pin (updated to >=2.8.0,<3), but more importantly, it also pins scipy<1.15.0 to prevent the BSpline breaking changes that were discussed earlier with the maintainers (@Aditya062003). It also integrates the requested Windows shell-specific setup commands into the README.md.

Since #430 is fully updated, conflict-free, and covers these immediate environment blocks, it might be redundant to have #433 open for just the torch pin.

However, I absolutely agree with your point about the Sense2Vec model . Adding graceful error handling for missing models in main.py (instead of a hard crash) is a fantastic idea and a much-needed feature. If you want to focus your efforts on that deeper code logic, it would perfectly complement the dependency/environment fixes in #430.

Let’s see what @yatikakain and @Aditya062003 prefer for merging order, but I think coordinating this way covers all the bases.