Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile with stable rust #5

Open
fafhrd91 opened this issue May 19, 2017 · 23 comments
Open

Compile with stable rust #5

fafhrd91 opened this issue May 19, 2017 · 23 comments

Comments

@fafhrd91
Copy link
Contributor

@fafhrd91 fafhrd91 commented May 19, 2017

PyO3 requires following unstable

@fafhrd91 fafhrd91 changed the title Stable rust Compile with stable rust Jun 12, 2017
@tailhook

This comment has been minimized.

Copy link

@tailhook tailhook commented Jul 26, 2017

Doesn't proc macro work on stable rust? (or just partially) And there is proc-macro2

@messense

This comment has been minimized.

Copy link
Member

@messense messense commented Jul 26, 2017

I think currently only proc macro for custom derive works on stable Rust, proc_macro_attribute don't.

@fafhrd91

This comment has been minimized.

Copy link
Contributor Author

@fafhrd91 fafhrd91 commented Jul 26, 2017

proc_macro_attribute is unstable, info is in linked tracking issue.

@tailhook

This comment has been minimized.

Copy link

@tailhook tailhook commented Dec 2, 2017

Can this trick be used instead of proc_macro_attribute ?

@fafhrd91

This comment has been minimized.

Copy link
Contributor Author

@fafhrd91 fafhrd91 commented Dec 2, 2017

no, it is not. pyo3 strictly requires proc_macro_attribute, because it requires access to token stream of impl sections.

@tailhook

This comment has been minimized.

Copy link

@tailhook tailhook commented Dec 2, 2017

no, it is not. pyo3 strictly requires proc_macro_attribute, because it requires access to token stream of impl sections.

I think this is exactly what it does, i.e. given the example:

#[macro_use] extern crate procedural_masquerade;
extern crate proc_macro;

define_proc_macros! {
    #[allow(non_snake_case)]
    pub fn foo_internal__stringify_const(input: &str) -> String {
        format!("const STRINGIFIED: &'static str = {:?};", input)
    }
}

The foo_internal__stringify_const function receives original code and returns generated code. You get a token stream using syn crate as with macros 1.1.

And all this works by wrapping a body of the macro into a type definition to leverage macros 1.1, to get a token stream.

The only difference is that:

#[mod2init]
fn init_function() {
}

Would be written as:

mod2init! {
  fn init_function() {
  }
}
@fafhrd91

This comment has been minimized.

Copy link
Contributor Author

@fafhrd91 fafhrd91 commented Dec 2, 2017

I see. But that would be quite large task, I don’t think I can spend any time on it. Also there is specialization, I am not sure if it possible to avoid it

If you want to work on this task I can give you permission to repo

@fafhrd91

This comment has been minimized.

Copy link
Contributor Author

@fafhrd91 fafhrd91 commented Feb 15, 2018

this features are stable now, const_unsafe_cell_new, const_size_of, const_ptr_null, const_ptr_null_mut

@termoshtt

This comment has been minimized.

Copy link

@termoshtt termoshtt commented May 3, 2018

Stabilization of TryFrom has been reverted rust-lang/rust#50121

@fafhrd91

This comment has been minimized.

Copy link
Contributor Author

@fafhrd91 fafhrd91 commented May 3, 2018

pyo3 does not use TryFrom

@termoshtt termoshtt mentioned this issue May 4, 2018
1 of 3 tasks complete
@termoshtt

This comment has been minimized.

Copy link

@termoshtt termoshtt commented May 4, 2018

impl<'source> $crate::std::convert::TryFrom<&'source $crate::PyObjectRef> for $t

The macro pyobject_extract! uses TryFrom. To use PyO3 in stable rust, this library itself must be compiled with stable rustc.
IMHO, there is no merit to use this unstable feature, and should be dropped.

konstin added a commit to konstin/pyo3 that referenced this issue May 5, 2018
This was discovered PyO3#5 (comment)
@konstin

This comment has been minimized.

Copy link
Member

@konstin konstin commented May 5, 2018

@termoshtt Good catch! pyo3 implements TryFrom, even though it currently uses PyTryFrom instead. I put a feature gate onto the implementation of TryFrom and removed the try_from feature. Once TryFrom becomes stable, we can than replace PyTryFrom.

@termoshtt

This comment has been minimized.

Copy link

@termoshtt termoshtt commented May 13, 2018

Drop of fn_must_use in afcc87e causes many warnings

warning: `#[must_use]` on methods is experimental (see issue #43302)
   --> src/typeob.rs:154:5
    |
154 |     #[must_use]
    |     ^^^^^^^^^^^
    |
    = help: add #![feature(fn_must_use)] to the crate attributes to enable
@termoshtt termoshtt mentioned this issue Aug 22, 2018
3 of 3 tasks complete
@konstin konstin added this to the 0.5.0 milestone Sep 17, 2018
@konstin

This comment has been minimized.

Copy link
Member

@konstin konstin commented Dec 15, 2018

Unfortunately not, specialization is still not stable

@pohutukawa

This comment has been minimized.

Copy link

@pohutukawa pohutukawa commented May 30, 2019

I'm trying to compile a Python manylinux wheel using PyO3. I know that it requires a nightly build, but isn't that (by now) a thing of history? It states the requirement of 1.34.0-nightly, however Rust stable is now at 1.35.0, but I'm still seeing the build fail (see below), though in my perception 1.35.0 (stable) is >= 1.34.0-nightly.

Any insights?

Error: pyo3 requires a nightly or dev version of Rust.
Installed version is: 1.35.0 (2019-05-20). Minimum required: 1.34.0-nightly (2019-02-06).
thread 'main' panicked at 'Aborting compilation due to incompatible compiler.', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.6.0/build.rs:540:17
@bgw

This comment has been minimized.

Copy link

@bgw bgw commented May 30, 2019

@pohutukawa

my perception 1.35.0 (stable) is >= 1.34.0-nightly.

Nope. Nightly builds have additional feature flags turned on, most of which won't make it to the next stable release, so 1.34.0-nightly has a lot more features than 1.35.0 (including specialization).

@ikamensh

This comment has been minimized.

Copy link

@ikamensh ikamensh commented Jul 3, 2019

I find the message confusing due to the second line:

Error: pyo3 requires a nightly or dev version of Rust.
Installed version is: 1.35.0 (2019-05-20). Minimum required: 1.34.0-nightly (2019-02-06).

I wanted to create an issue about this, but luckily found this. Also, how about telling Python users who are newbies to rust how to get the nightly version right in the error message?

I did it using
rustup toolchain install nightly
rustup default nightly

@joelberkeley

This comment has been minimized.

Copy link

@joelberkeley joelberkeley commented Sep 29, 2019

Is specialization required for both using Rust in Python and Python in Rust? i.e. can I do either of these on stable?

@AndreaCatania

This comment has been minimized.

Copy link

@AndreaCatania AndreaCatania commented Nov 18, 2019

The path to stabilize the specialization feature still seems long, the tracking issue was opened on February 2016 and still there are a lot of opened questions there.

In the meanwhile that we wait for this feature, would be cool try to not use the specialization at all and so allow anyone to compile with the stable compiler, even if this mean change some APIs.

Is really so necessary this feature?

@io12

This comment has been minimized.

Copy link

@io12 io12 commented Dec 6, 2019

@nickray

This comment has been minimized.

Copy link

@nickray nickray commented Dec 19, 2019

@konstin any thoughts on whether dtolnay's trick https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md linked to by @io12 above would be a feasible/pragmatic way to for this library to compile on stable?

@TheButlah

This comment has been minimized.

Copy link

@TheButlah TheButlah commented Dec 21, 2019

Having to use not only a new programming language, but the unstable version of that language, is not something I feel comfortable pitching to my coworkers (no matter how stable nightly actually may be). Because easy python interoperability is a necessity for any new language that my work would use, and because it seems like there aren't other options with the same level of python interoperability with Rust that Py03 provides, I cannot in good faith pitch using rust at work until this is using the stable version of rust 😢

@jcdyer

This comment has been minimized.

Copy link

@jcdyer jcdyer commented Mar 26, 2020

@TheButlah: You can create libraries to interoperate with python without using PyO3. Don't confuse the library with the language. You can currently either create native library bindings for your rust code, and interface with them using cffi, or use https://github.com/dgrunwald/rust-cpython. PyO3 provides a nicer interface, it's true, but if your requirement is stable rust, that interface isn't available to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.