Re: [tor-bugs] #25639 [Core Tor/Tor]: think about Rust crate boundaries

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#25639: think about Rust crate boundaries
--------------------------+----------------------------------
 Reporter:  Hello71       |          Owner:  Hello71
     Type:  enhancement   |         Status:  assigned
 Priority:  High          |      Milestone:
Component:  Core Tor/Tor  |        Version:  Tor: unspecified
 Severity:  Normal        |     Resolution:
 Keywords:  rust          |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+----------------------------------

Comment (by chelseakomlo):

 Replying to [comment:6 Hello71]:

 > Replying to [comment:2 chelseakomlo]:
 > > I don't think is a good idea. I agree this makes it simpler in the
 short term but this won't scale well. I.e, we definitely want more
 modularity in Rust/new code, not less.
 > >
 > > Have you looked at how Servo handles this problem?
 https://github.com/servo/servo I think we should consult more Mozilla
 people about how they have handled issues like running tests, linking,
 etc.
 >
 > I will investigate. AIUI their situation is different though: servo is
 intended to be a fully enclosed module, if primarily intended for use in a
 single application, whereas in Tor we have tight coupling between
 everything. possibly we should consider having several distinct modules,
 but in that case we need to discuss how we draw those lines;

 Yes, that is fair. We most likely won't get these lines exactly correct
 right now though, so let's plan on having several distinct modules, and
 being able to evolve this as we learn/refactor code, etc. I think this
 ticket should be an ongoing discussion, as opposed to "let's hammer out
 our architecture right now." Flexibility will be a good asset here :)

 It is a good point about documentation for module planning- I have some
 rough notes, as does a few other people. We will compile these and make
 them available.

 > doc/HACKING/CodingStandardsRust.md:
 > > If your Rust code must call out to parts of Tor's C code, you must
 > > declare the functions you are calling in the `external` crate, located
 > > at `.../src/rust/external`.

 Yes, this should be followed. And we can talk about whether modifying this
 approach makes sense- maybe every crate has an `external.rs`, for example.
 But isolating our external C dependencies is a good idea for enforcing
 clean Rust/C boundaries.

 > Replying to [comment:3 chelseakomlo]:
 > > Have you looked at how building is handled in `tor_rust/lib.rs`?
 >
 > I think you mean `tor_rust/Cargo.toml`? Yeah, I understand how it works
 now, I just don't think it's a good system. I'm open to being convinced
 otherwise though.

 This is taken from Gecko project structure, it would be worth talking to
 them about this setup and any issues we've had with it thus far- maybe
 they have already ran into these problems and have ideas about them?


 > I will investigate.

 Thank you! This is definitely a lot of work, but getting this right will
 help us have a sane/maintainable project structure into the future. Thanks
 for the effort and looking further into what our options are.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25639#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs