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

**URL:** <https://discourse.julialang.org/t/beginning-a-project-to-automatically-convert-scripts-to-package-style/62558>\
**Category:** Tooling\
**Created:** [June 8, 2021, 3:50am UTC](https://discourse.julialang.org/t/beginning-a-project-to-automatically-convert-scripts-to-package-style/62558 "2021-06-08T03:50:21Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![emsal](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/emsal/32/9729_2.png) [@emsal](https://discourse.julialang.org/u/emsal)\
**Post date:** [June 8, 2021, 3:50am UTC](https://discourse.julialang.org/t/beginning-a-project-to-automatically-convert-scripts-to-package-style/62558/1 "2021-06-08T03:50:21Z")

</div>

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)](https://github.com/emsal0/PackageStyle.jl). 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?

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [June 8, 2021, 9:53am UTC](https://discourse.julialang.org/t/beginning-a-project-to-automatically-convert-scripts-to-package-style/62558/2 "2021-06-08T09:53:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![emsal](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/emsal/32/9729_2.png) [@emsal](https://discourse.julialang.org/u/emsal)\
**Post date:** [June 8, 2021, 12:40pm UTC](https://discourse.julialang.org/t/beginning-a-project-to-automatically-convert-scripts-to-package-style/62558/4 "2021-06-08T12:40:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rikh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rikh/32/204104_2.png) [@rikh](https://discourse.julialang.org/u/rikh)\
**Post date:** [June 8, 2021, 12:49pm UTC](https://discourse.julialang.org/t/beginning-a-project-to-automatically-convert-scripts-to-package-style/62558/5 "2021-06-08T12:49:54Z")

</div>

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.