Indeed, and we plan to do that very soon. Due to time constraints, we've initially moved it inside TF core, and from there we'll extract the reusable parts into a standalone repo. We hope to have that set up by the end of this year.

@KOLANICH,

Sorry for the late response. The autograph moved to a new repo and it can be accessed as tf.autograph. Thank you.

Thank you, and everyone involved into it. 🎉

The autograph moved to a new repo and it can be accessed as tf.autograph. Thank you.

It hasn't been moved to a new repo:

This repository contains tests and example code

Yes, this is still an open issue (I think @chunduriv was referring to autograph being available in its own namespace). Mainly because we need someone to set up and maintain a separate repo - otherwise, significant parts of the source code (tensorflow/python/autograph/pyct) are already independent of TF and could be mover rather mechanically.

Commenting here for visibility. We have made a static copy of the autograph codebase for use in a framework which builds on autograph to convert Python functions into OpenQASM programs for quantum computations. We did not want to take a dependency on TensorFlow, so the quickest path forward was copying the codebase and making minor modifications to decouple it from TensorFlow. We would be very interested in consuming autograph as a standalone package, if it ever becomes available, and would be happy to help validate the work with our use case.

Here is our copy of the autograph codebase:
https://github.com/aws/amazon-braket-sdk-python/tree/feature/autoqasm/src/braket/experimental/autoqasm/autograph

More details on how we are using it:
https://github.com/aws/amazon-braket-sdk-python/blob/feature/autoqasm/src/braket/experimental/autoqasm/README.md

Hey all, having autograph available as a separate repo would also be super valuable/important from our end. We're in a similar position to @rmshaffer -- we're depending on Autograph in Catalyst, but don't want to have to depend on the full TensorFlow installation for users of our package.

Would it be possible to split autograph out -- without the TensorFlow dependency -- into its own PyPI package? We would be very happy to help out here :)

It's certainly possible to split it out - autograph was designed with that in mind. Besides some dependencies in the high level API that accumulated as technical debt and should be easy to remove, only the operators are TF-specific, so as long as you have replacement for those (which I suspect you want anyway), a split should definitely be doable.

I'm not sure if there are any concrete plans to do such a split, so I'd recommend taking the lead and doing it.

Hello TensorFlow maintainers, I'm currently tackling the separation of TensorFlow and AutoGraph as a contribution to TF.

I have a question regarding the preferred code organization, for which I could see the following options:

• keep all code within the tensorflow repo, while separating out build & packaging processes etc.
  • Following this model, either of the below could still be taken as a follow up.
• keep all code within the tensorflow repo (as above), but also make a mirror available in a separate repository
  • I believe this was the model followed by mlir-hlo, although that code has now moved from tensorflow to xla.
• move everything to a different repository, for instance the existing autograph repository
  • I believe this is also the model followed by the tensorflow estimator package, which is also available as a separate pip package.

I think the last option makes most sense, at least in the long run, although a clean move would not be easy to achieve. It would probably be most practical to start with a fork, and continue improvements there, while in parallel configuring TF for an external dependency.

Hi,

Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.

The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.

Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.

Hi @tilakrayal, thank you for checking in. I don't think the latest TensorFlow release is resolving this issue, which is about separately packaging and releasing one of the sub-components of TensorFlow.