CJ Wright
Christopher J. ‘CJ’ Wright is a member of the HPC team at Citadel. Previously CJ worked at Lab49 as a consultant and software engineer helping to advise clients in capital markets on strategic technology goals and build state of the art systems. Prior to his work at Lab49, CJ earned his PhD, MPhil and MS in Materials Science and Engineering from Columbia University, specializing in streaming data processing, data provenance, and x-ray scattering simulations. His work has spanned from crystal growth characterization to NASA Mars mission tomography to software support for complex experiments. CJ also holds a MS in Chemical Engineering from the University of South Carolina and a BS with honors in Chemical Physics from Brown University.
CJ holds various prominent positions in the open source software community, including a seat on the Conda-Forge core developer team, chair of the Conda-Forge Bot and Finance sub-teams and is a member of various other Conda-Forge sub-teams. CJ’s work on Conda-Forge helps deliver high quality software packages to the broader community and has earned him an award from the NUMFOCUS organization for his contributions. CJ is also a contributor to other important libraries in the Python and data science communities, including the regro project, streamz, and xonsh, among others.
CJ grew up in Rockville Centre, New York and currently lives in New York City. In his free time CJ develops for open source projects, plays woodwind instruments, and works out by playing squash and sailing.
Session
Defining dependency relationships is a fraught but integral part of the packaging process. Incorrect dependency definitions can have catastrophic consequences for users and the broader ecosystem. One of the reasons that specifying dependencies is so difficult is because version numbers are very loosely related to the actual property developers care about, the API and ABI. Software doesn’t break if any API changed in a dependency, they only break if the API it relied on changed. Most version number do not capture this, providing a global view of a local problem. To address this, the symbol-management project has begun to catalog as many symbols as possible in the python ecosystem. While this was initially aimed at enhancing conda-forge’s dependency metadata, the implications of the database are much greater. In addition to providing version constraint suggestions on dependencies, the project also enables the creation of version numbers based on changes in the project’s symbols and determination of if a code-base is compatible with a given environment. In this talk I’ll discuss the structure and motivations of the symbol-management project, some examples of how to use the project, and the future of the project.