Beginning a project to automatically convert scripts to "Package style"

Tooling
1

heya, I’ve done a small little script that parses all the using expressions in a path (directory or file) and adds the packages them to your directory’s Project.toml using Pkg.add : GitHub - emsal0/PackageStyle.jl: Turn your Julia scripts into FOSS-ready code (WIP). Thought it was a neat idea but I’m still really new to this so I wanna ask:

  • Is this even the right thing to do? Am I being presumptuous by giving it this package name and what not? Does something like this already exist?
  • If it is an OK thing to do, are there any really obvious optimizations I can make to the parsing->getting using expressions->Pkg.add-ing them all procedure that I’m doing?
2

It’s not a bad idea, but I think the reason this hasn’t come up yet is because there are basically two approaches people use to manage their code: 1) throw everything into one environment or 2) preemptively create different environments (with src, test, etc) when starting a new project (even though it may not ever be published as a package).

It’s usually a good idea to already start with a seperate environment for each different “script”/task/project. This prevents weird dependency collisions caused by dumping everything into the main environment.

For example, my main environment (v1.7 at time of writing) just contains Revise, BenchmarkTools and Debugger. If I activate another environment, I’ll still be able to do using Revise (since environments stack with the default environment) without having to add those as a dependency.

1 Like
4

The goal here would be to make a tool that can turn a project formerly done in style (1) to one in style (2). I’ve recently run into the issue where I have a bunch of experimental scripts that grew big enough that I want to turn it into something “real”, but refactoring them has become a pain.

1 Like
5

I would second above advise to bite the bullet and refactor it manually for now and in the future start with a package straight away.

For example, I have some backup scripts of less than 100 lines of code in a separate package. This allows specifying versions for dependencies via compat and more.

1 Like